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ERSTE ZGTÓT a. araáe 0 GEES ÖS Ú ál tuáedeleneorttááor Ta. bu cástr ab a álta eoglt sb égi ZER 4-8 59 
Ismertfelhasználásolkó: : sssz e svsésdrérs K eges É KNÁ TK lá ak nek 6 etés íg 4 éj 63 
Sapesalódó MMŰNÁLC er a Asz 3 zési ák kk gitáron 4 tól ha sás gén leg érégyel de 1é mmőlt 4 hg. 046 164 

SERZÉTÉKŐT rite KÖNEG E 2 SL IME 4 HOS s ÖVES ló Ged ÖNÖN ÖK SZENN MÉsjátb e AN Bet HÁT 165 
EGYÉDIMEKÉLG Fr ezis edit EE EÁ égen ZSEB HZ ÉG TAT EV áje re tyá lá 65 
CS a azért és gye: 4 akt EE ÉS 6 9 ÚRI E 9 dási 4 akzáéoé pr örgéd har turáb e: ú ésa hb. éli 4.-ő án 165 
SÍN Ét éz GEL (gé tések úg aátél4e ák ábikáteét ő trák út Vé dbtésűlk 6 Jatkelyye aa af megl de KE ÉS JÉN ÉT Ég 165 


Programtervezési minták ix 














ZETÉNEZEÉ a ant áe sé vk él sé eláll be vétó vá EEGÖb És E ZEÉLNE (E KN É ÉN ÉL TÉT 6 ZA ALÓ 167 
FESZÉVÉKŐLS ríéra ő 8 ette e vésza tó JELEZ fent Eden a 6 Mig 46. szére ily 4.6 lee 167 
EGYÜMÜKÖTÉS : : set ég at Eh 1aa et 0 ET VÁ ET CIzá ÉSA B size eső köss 168 
JSENAELÉ LES ATA TÉS ÉL TÉS sárnel kk ertsd és 0 tsáőra ar KŐ 3 Varta See rátér Ő éssel 6. öllek erek bat §i 168 
TERVE HŐLSÁ ÁS drog íz 46 steotébtés 4 ag lárma tk E salt, ől VÉGES La étta s [d -gstáylv ÍE, Hl MAN ÍM OF ÉGRE d 1€ etsÉE ÍZ 169 
BELÖJKÓÓ : ret éa KESZ ELÉG ET ÉN 7 E E EP TI EOK EL BETE TB EBA E: Kék 172 
TEDJSEL TS RASZAÁÁSAÓS a sérv ő 4 sek s 4 sw 4 ete e 4 ását 4 6 denk 4 4 1 HrZOIY 16 ák dnáátat he 175 
TEL GYÉSETÉ TŐLE ÉNÉA B sre BB té tos 4 2k etek, Bak EKG AK lt HE JE at ÉRÁK ante E 57 EGÉR ebnteÉ 76 
IEGMTSŐ o 4 4 éléés 4 4. éva 4 MÉR 9 E AR A ÉVEL FÉMEK ÉL HES 4 EVEN É A AAA Ó 1 Ő CK FE LEE 177 
CST atát Bá él 6 S KK ölés s 7 gbktk vá Ke éjee ELÉ NEC aROK Él Ő gb a 4 VÁ z7 
GNÁTÉBTT son dsza s a Eőa őz ali a GETE Ba E ÉL GÁT ús Úrnál. akk é0NÍS zk 
FETT zona áz ő algri Aú KÍRAN 4 att a EKE al átére ő INONK A e ÁTEY §. 4 E 7-4 HEZ 44 EÖEG "gá 
AIKANIAZHÉSÁS 4 sé té 0 E Késő kivlé s e heáén éa 9 ákénk úr Vak G út al does 4 4 ázási 79 
TEÁS ÉN ÉSZ GBT ez jel5ÓRVete Al ály Ölel béke e DE §e el 53 sör NEL ŐSÉT gyÉNNÁÉTE 79 
RÉSZÉVÖVŐR zza ao atast ára etéee s. d égató bd atbsls Aa a alék a a szot bd ea b ége a § ÉG 180 
EGYÜLÉLÖJSE c str E NT ETSIÉS E ÍS LELDA EZ ÁÖG hó Eta vő oral 80 
IGAZG KEZEDET S . psázé ik Gy 3 E eSglb 2, hg Hénlkt fer klöébik e panll ás dett Ah Al önts; to HÉT 80 
EGGY ÓTTVÁLS szetss ő al stee tr ea agrbegs 44 ára tE 16 ék ELNE E HÜ KERETE 1€ HÁTA E Ah NET 46 AV he öltátet, hay e At 81 
Példakód 83 
Ismert felhasználások 85 
HA AESŐLÁ ÓN intés e dtéktáeta ál éjestré he 4t TŐKE Ér ak ata d AL av Íge eeldtás al 18 EOK IE, HL -eÉKES 186 
ÉTOMŰOKZÁB a ser wz a ezt ea BENE KÉNYE E Mt 8 4 003 4 BÉG EZ HU 1 K tvé 4. $ VKLN 87 
EEEN TES S. lé ád gl SSE Éj EGÁL lé dkg 96 aj nÉNt Ő KÖLÖSGE ER ÉGAKÉ d He öket átt Élete 187 
KA ss a sé 6 ögelá ő kén § úsápy hé Géa PA Állj teat ösi Írj árás E ALK ZLÓK irányt (et ségttáe 187 
IREK sr evslsa 4 eb élsltr A arat 4 d élni ha stáE Ae DAN 74 ÁD E ÁE TE E JÚ 187 
JALEZTHAZNATÓSÁÓ re vét Vad 4 Vssá E áá Ez hasú ba bell ba báté e § kign § tök 188 
SZENES Eat írt slsát hé álöbés AÚ kel BOKTO B Eg AE d GÁL eb LO ÉE ÉG öten ask li 
Résztvevők 
EGYÜLTÉKÖCÉS uz 64 éle: En Et Hós EZ ÁS Ah GEL FÁNAK KT ÁRT S ős KE ál 189 
IE KGÜSSZTES S, a eljesti E ágon le Mg galkoe él Zalak, A, Üss ÖK 6r b Hetes Áost S SE ő dl 190 
ÁZ EGTALÓSÍTÁLS ar tél rőt, E KENÉA ég AE AKT ld. 4 vertek Írd sa. öltés ht, tlsató 4l-at talon át d véte 4 4E feleamm §. d éles 190 
PÉLdAKÓÓ a4 LENKE EE KÉS ÉRTI TALALT VEK FG SÁA E 4 VETEK PH ET PE 191 
ISERETET SAS ZATA si ős gágé ld 4 misére d dozkéyea ktg kon köles e tákésás zó 4 áá b ágébő 194 
ESzj alorelbeda atiani as 1-1 ij ERZEKE KET ESEK 196 
PEhelysülkrő. a siras a tét az et 4 Béke BAN KG AN E E EGB TÁ 6 E b St 4 Ún 4 2 ai 196 
BEVELHEKEK £ öt £ 4 ús ved ÚÁLG I sáki zár keéré ét vésse és 6 belt 64 keszk ee sat ke ánásgő 196 
TELE jjetr Él THAN ág ej HNK Éő aláz ZÁ SLELEK, Ó VARTÉLÉ LÉ NGÉ E ÉLTÉ iértrtlbS ő SL Kat ÉLI 16 ef 196 
TGJLŐLAÉ a eszébe ését 9 4 TŐKE 2d et date és aaa E GÉNT a. a. VES AE 0 E ÉG KN ZTAGN A TÍZ 196 
ALKSSZNAÁTÓSÁÓ 3 r 4 $9E 53 KÖLT ÉTER E EÉT EÁ E E háát zh a sét él tenjésk, 47 ése 199 
MZESSZETS izé seleátlák tés ájejtan 6.Ét iréadkl 4 ZENÉK és ÉLÉT Sa dbrle e gy SRE ég. 1 HjNES 0 Íb lsKSS Ké 0 200 
KESZÉZEMŐ ra ee jb-ár net 4 akta 4 AL DÁkÉS KB aestt a 6 lé a al ölt kal As A A NÍTE 6 ET 201 
EGYÖTENÜKÖdÉS ey zt épp FÜGE TT ÉL KE SRETT9VŰ S E NILŐ E Egé s Ét dá 201 
EGE KEKKEÉTTŐK 2 eatáa 4 gé a E eke a ő érek kg Út és 8. tea 4 Gaal 4 6 ÉdlbásA 4k téll 201 


xX 


Programtervezési minták 





Megvalósítás 
Példakód 


TSZ SSALGELÁZÁNTATS z salátérk ése ztszat ss KÉRY 5 SNEK B VÁG Elle a érdés 40 ilag új 
ETSÍMÉTTSBL ra szet íze étre gs tkatts he PK EL ÓL KÁ BOE Ükt 2 ető lk tata éz ék kán aaa ggg 1 4 te a 
Cél 


Alkalmazhatóság . : segg e túr ése ris ae ván ú saga bő a d kátg gek 4, 
SZETKSZÉŰ 52 TONY AZ e ő alien Get 5-4 én 4 ÉS JÉG UI E. E ZÁRL a gú a dal ee d 
Résztvevők 


SORSÉREZETÉNTŰK úrrt 4 kád 45 zakó ááltk fé CNN HE ő ENE BAK E EE sánta 
IEESSELTHTÉB ask gnői ba hös óttkat 74. 1 ATR KE RÉT 6.3 ÉLÉSE E a isrlag a a ési úr inéser ál is ige 
BELTAKŐET a vén k aszt 6 ály A. 2 HÁ ZD ÖL 4 46 együk pa tása b ág iss A ágat. 4 ggg 74 úly 


JESSEL ÖNÉRT; salt digi a Vekpe ty AY E ÉN E 3 BA ask eövetős 4, őszi 


ASZETKSZEH ANÉkYŐL e a a ézesa e 9éteg EE § 4 in 4 a veg úg valós §-ó ugya N46 tha 4 4 piat 


ÖS kél ú s vétó éezkáneb ér mmalgétl s kelta éz NT 33 TÁST NÉ g Heléltár Ésa gek ÉG ál igstd a. esáty 4 


Következmények 
MEGVALÓSÍTÁS rea €imezik mis ég NY E ÉTYT Ő dográg 4 a 6 állók ék és árdleri égés élt a muggtg a get 


EAK vs ető E GÁK EK KE E ülik é 4 dett ér b Ükáeyl vine 4 ate a b ÁLL 4 E éJ ez a, 


KAPCSSIÓTÓ NÉ] o a aság él a SZEGTE § lá 4 4 trágp 4 ói ertaák fed era 6 atarg, a  he 
Parancs 


ZET ENETÓ e ég hg rem 0 AKT BÁN ESÉL E) ÉGET ED lsz GZ leg a d Egé lg d dékán e seg 
FOLÁMAÉG s övét azét 5-s NP EE EÁ EE süni te a tdgárik gekkó e lást gy sétyos sa, a ja 374. gar 
AIRALTAZNÁTÓSÁB SZE § sss E sntátá kaá s a árak Bank ÉRZEL EÉÉK E d husi 4 eu 
GEES Este táttog láz Előn éNÉÉ ÉTÉ AVE E Alé s el sás ÖV lsezg zsák a 





Programtervezési minták xi 





Nisesalósítáls : a sszeserő áréunn ep ezé na étiem té áras gé eaz a TREK ÉG ETEK EE E 242 
ÉL ERSŐT veávtey altt eezfa 55. 7. agpstéstnák Úá lk jgjeár ét §lvölén $ó b ölnek Írvé gémek lk Ál esándk e el. 0117 HÉTŐ 244 
TS ErE fElhaSzHAlások r rat zt úg ké ang e dot b a Ea ed zttk ad dorákkak te al mo ér 247 
Kapcsolódó minták .. . . o. esse asunyes ezret kons ad VEL? 6 TK TB 449 247 
TV ATEKEZŐ irsz est telket gát netet d ate e tE Set E ködbe ár bells 4 3 else ŐS za AK ÍZGA ÉV 248 
BSYEDHEVEK sites étek epen a ret ő u sét a 4 Naa TA tok éa ha 9 ázat 4 248 
(ŐL. ő srte ie másé seg, útpb a d tvalán mó sás BE ÉGG €E BUZ FR EVAÁS E (Mek 4 EZET LETTER 64 248 
DENT -aa 14: zans Gé sét od ÁR Ér tötboáe ri Geln ák slat he váz ángelg9 Sa él ét e ége 4 2 leszállsz 248 
AÜKZÍTHAZMALÓBÁL a tri a a sáv 4 a tsals a Ésa 46 enatósa ré pb ék kesve ía Ök eként Írj glásá bs 250 
SKAN , , su ea só ré ÖS EE ÉVE FT ÉÜLIL TT CÁNK E 40 41 PTE L A GSÉ E d EBA 251 
TÉNEK árnál ő ő ást § drétin a zotya 44. vb 4 ának 9 hébe 544 vad d 4. VEG BÁLT 251 
EGYÜTKTÜKÖÉS : a mersz a tátva a érése 4 4 ernnt 54 sntétte évé MESE ÁÉ 1 d vésse A Üggüské 44 matáe 252 
KÖVEÜKETBÉNYEK pzs tév rt HÁEE E SGI 4 A RA § VEGI 6 4 elte Je aa atdék a arai he 252 
ÁGESALÉSÍTTÁLS unér láésé eller ét ha ar égaatrk 4. easő 62 Szó ké ÓZ b E ANG E DEL 252 
JELEK STÉT a. te etén cat ante za la tré Alvás ssel ÁG sós véli tál, VÉ d TE E Ét 6 eb ZA. ús AÁK Sa 9 ÁLTÁAEK 253 
Töriért TElhASZHAlÁSOK ra seá a Ezra kv Dee E A mál a sé mesésé d ézésota íz a sókat 261 
Kapesalódó mitlák ... e ereny é vusagr ségét s ő SÚKA VEL ET ÉVÜNK TERE E 4 E A 261 
TB ÁT sza 1 Net, 3 GÉNSZtK 4 VÉGE ÉE LA seta 3L dr áömántó dl.-é: vedáads s, hágémető 54. ILLÉS 9 ÉGE fall 3§1 11 égbe 262 
GEL kt éVés a d ege e átt a e öss 4 étsre 4 Gé mt ák PRÁGA a eln NÁLT AK kt NK e sát 262 
ÉGVÉB HEYEK. . ors sz nüt a nesz b 3 da 8 b bBŐ E SPTLTT MAG 4 a Ér DB ÜG EÁ EN 262 
JEE TÉHEÉ 9. armén 305 jehagáte ál gb olt Étter lk ágra tk vék kööknán § 9 éel hráredlt d 4. k ill 6 3k bb Á E ÚŐÉÓ 262 
ÁSZT HEZ ZHATÓSÁL hr az teesr is East 6 öelallk ta zatlan 94 Rtl ÉG al leget 4 al epehkák rk dejeétrtt 0-1 264 
SZEHEEZBE rea gave ú a als 6 4 TÁ E E BG E TLÁRK KT VEK E GÁ E ELVETK RK ATA aA 264 
NZEKŐNÉE ús 4.2 sag élet det éztts dr sel a rés hb 1466 üresek ól 4 éviésó E 0 IRS É Ő 265 
TBGYGLTŰK ŐT ÉS zs ta a etyéék 41 át rag aes ak im melák 4 a drdávbs Ta ge hel SA - vösdpak 66 nal 417 vlk 265 
KÖZSMSZMÉNYÉK 402 eyes é kr váng ke kárt 2 Útra ame a 6-s hbe ea tát Wleett 265 
MEGVAL ŐSÍBÉSI 2. aámrés rzáorék 9 ekben 4 a sb 4 4 belét b sál 9 VÉSŐ 92 GET ÉN ETT 266 
CN et gáir LR RETÉTÉR TETÉSE 268 
Tét félhásztálásók : est :záút a a mds a ere és vá adta a almát al Él ra ő eng e 276 
Kapcsalódó HÍRŰ , mán ere évietai kád d FOG SÁT ÓTA ETELE Ő 276 
RÓL GÉ Ő trák 1 ágak al al elk as lnáa dá vdtlntet 5€ hel evbe ÉsÉS aj. S ha. 6. mdévöeÉn 6 95 A E NK 277 
EGYÉDDEVEK 5 zt ézr éz rési a krénez ő etve a dates al ar NAN a 2 Vigye al Ér vég 16 Sás AfVéáKK tti 277 
MEL s ráz séné ék éráérásés a vét PGDÉT ENG TD SÁGI FK EH TE ÁE ET ÉSE AS 277 
ALT as áz úsatákas 46 SE DRN Ú7 agnákik is sötet Elé, ntést je je. Anlákék só eevéslleől e 6 Tés 4 RG Ő 7 lt ő 277 
ÁAlKAMAzkAtós5áG e more e 3 véres dl tészta ta at közök 16 ák ápsákár élt 9 ERR 1E-d ÉgMtA TÓ 0 alles 4 d ASŐ ÉN 280 
SZGÉGEMET . a stee a sé e 5 EGT KÉL ÚEŰN FE Gál KT ÚN T 4 ÉN 44 VES E vér 280 
MENÉGEEEÓ més s kék e ÉLEK L S SAN 1 elé Vál ebét ah ön a Ő E GÁ B 281 
EGYÜLTŰÜKÖGÉS a 2 ösze ú 7 klet aa ásrájti tá a mvátós da VEB 04 él kezén 6 dcislé jea ránt 146 elenk ha 281 
KÖVELESÉMÉNYE reszed gat: ? éa: E Áhű KT ETET EN ÉTÉ E E tree e a E áh nk 281 
Megvalósítás esos sávra a énée ra met rk ületesé kp ne 5 ná E ETELE EE MEN ET E 282 
TÖKÖLÉGŐ a a a tré a al tat dl aa úly ák lk Az ha K ÉN E 1Ó KDE a d ONE A B ésNE 1 4 ÁE 282 


Ismert felhasználások 
Kápcszlódömüsk . ..... . sereg ang ea szét e GED RZZA FÉKEK FO TSÁ ÜK TM 286 


xii Programtervezési minták 





E TEREÉS TŐ erő ezt eték d égápá irás bo 4 SZAKK 2 EME E E ÁZÉNEN A NT ELÉ 287 
CE]. smégés ők szdöntt ha. eő dea 12 4 Ég a EG 2 EG KÉK EZ kás néni £ 4. Kár 4. keríti 287 
EGYSBNEVEE 2 egy: tart kás; szep e tiuát k kádék a ása he kiterni bő keeéözéta 4 átrzés 287 
HETREAT o zeke 4 üdlze a Zkátsk És A tes Éden beritee tú nódn KDE EESZBE 287 
AKA TIS Z HATÓSÁG kn zs rétet 4 te 6 VÉ 4 EÓZEZ LA TÉN ET ÉSE 3 a salsa ee álá is ő éa 289 
BZREKEZGÜ nos éz VOT EZ ÉGE ET AM E É TÁR E ná 6 3 fatéréj ési 9. ölj ák öntet át As ágeás kk rgéssái 289 
IERELN ÓÓ Ab igás ar AZT Tágas SK ÉG ÉL KÖGENT Ek ves GÉ Úr KSÉGES ESET SAN a SÉT 289 
HEKÜENÜKÖHÉS ses ő esése etette ágba a ÉTÉ €h ALLA E ÉBE EZ uz sg ugyi 290 
Következiményelt : sztk: 9889 6) gt EE ÜGÉE s üveg ámoi 4 4 éreát 4 vi igy út b resré 290 
MEGYZTOSÍÁS 4 ás vető úr dts hg a Gát ás esdekel údkér áró séget 34 AÓKÁ Ár A tág 8 dl sg 291 
ÜRÁGÁ KÉRÓ sks ázó kele ot AVAG E bát TÁ god TON LA HÉ TÉS EB 2 3 NÉK ÖNKO S 292 
Temértfelhasználások mere meg azéy E 4 At k 4 ES ré sazne E 4 gessé. az úépát ék dsáins úk 294 
Kapcsolódó JŰNÓK : cvs ő s veg d d vairáos o au pé ses sztss kn aan dt A. 6 fás ő 295 

TESZEL e s iii 4711 sl áz kb le A eltyá 35 leggel 4 dégylée 4-aletsén ae lt 5 EME 3 ÉLEN TT EK 296 
TB édi várná 49 HE lest ák 4i. df 4. et TÉN 5 § ÁTÓE DÉL E E S Age k 2 áá 4 4 bosák £ a ésénée 296 
EGYÉB HEVŐK gl EÜ éÉ ET SÜN § ék vő été a arszt kk árát va ák is táséták 44 ok íg tti a 296 
IEELATRŰ aa dea elsok e 3 klszár s, a SANÉS AL A ÁGOST JBL ea ldagaad tétésntságt a KANTREB ÉS ÁG et et ÍLÉR 8 296 
ALBZTOAZHAKÓSÁL a e nvatsás té adat NE E E DER E E IEEE ELETE zető késsen 297 
SZETKEZBŰ a s 2 ME 4 EZ ÁNÜL E E ÁS E ÁÁnE SE 4 ége 4 4 delle 4 ázni ha leamáok, beé egál e 297 
SETS É EH 2 dkg ar igás eat nert úg vető Te: d gelts ége aga la OVER 4, MRA INÉBEE S 298 
izfzajgbtunnata] 40 a1 sztájk zARARMESANAT ETET 298 
KÖVSÉKEZMÉNYEK : sén ét 00r re EZEK PEGÉ KG úszás ár ksótá 4 lna 4 4 látás 6 4 vigyrést -é 299 
NESNRLOSŰET ZO AK tg EE KG ÜGÉ Z Ösátelk A Ág ő hal B E KAÉKCS sí Ap JÉ TÁÉL E 300 
LE ALCÁZ ÉSÉT ai övét téesés tét Ök ÁG elát 333 dög ee álennta XNENNEE IN GRÁg a SZTÁR EE LE ÉN ÉS 303 
TS TEASZNÁTÁSÓTÉ a za véde a GREY 4 ÚE 3 § BELE E VÖ kérdánat pó gs a a ágkáz Ár új 306 
Kapcsolódó TŰNtÁlS sza 7 zeti a 4 sshá a vese át amtár ák Évát 4 ingek áh an, ai 9. ZET 4 306 

ZALERTS Tét (ES Úgélez ja írlla És Kezdek te Öld, vé zás, Ae. Sa edbllág am mats e lk ÚGY EV 1 307 
EZT hat Izé 4 Énssk § életet a (ATÓ B HE TAKE 5. B ST ÁBE BZ ül 2 tekllé ég úisgé te § 307 
EGYÉDENEVŐTE sós pé th E MÉ § ÉGE 4 észül 4 d tsele 29 álá ör ádénesk igája áe 4 Hiatgtgyks úr- 307 
ELÉR ÉTÓS 5-9 e iAgÉ Tá Ölel ék Aréna ök Ká Ök gét boceltalbbágy a fééténel a. DON ÉBE are 307 
AIEZOAZNALNAG s stat 4.5 átéalb a tés KE E RE E ET Át FE EZÉ tes a deálá a a 308 
SZEKEZBŰ az a ná o E10glk 4 Ég 13 ÚGE Tb BBZÓ ZEÁ 44 a álása 2 onás b-t stl ieé iát kúl 308 
RESZ ETÁSES e E agár fé kánátó séta ése E És dtbet és § van úr VESAKSK a gé ésenb a. atebe 4g Cael et 308 
EZENNEL SEL őz rélégér e áréé 34 mskéke ési a mtv delre d 6 GÜRE E LE ÉRÉST E des erő 2 309 
KÖVEtKEztTÉNYEKS eaz éz 5 § 4é 4 elt KB DAL; § le dt vén bá ék dpágy nai dási tése 309 
IMIGYÁLOSRAS 64 2 ESŐ 4 Hitte 4 nils e ségek je. 44 ágtól rek dal kell ak at Hgyáatt 14. őv gázt at a 310 
DRSKEAKOSŐL LGA tárná ég ÉDÓ 4 útán KÉN fáté et SEB KS EOK E ZD YT HOSE ÉSE 312 
JAmeréTelhaszhálásblke : ess s e dé E Ent Eg Kál z ÉBE zi 4 sikásé eg a egaúk 5 éa 315 
Kapcsolódó IMŰKÜÁÓ s 4 p Aa d 4 jedi eameré zen deetá e 4 eset ár 4 énjét fecyáées § Kfé a 44 10. ék 316 

SEKZESETB éb eaelsk 4. E ése A ádkb Gr ÉLnát s  slksás út B 4 Sit MENO B-be b E BEál b ÉRE Aa 317 
GEL önbe só sórgábote Ap KT hé átálrt aes öbaksztéte ge 5 ESEN E GE B E LÉE a Ú ssal ő e dló ad A17 
HGyébEHENEE zs zat pp ge: ésGA EP 2 tató 4 éke d nsák évá elni ik 46 itta ra, út sága H17 
BEETÉ SG ÉSE 2 Örsluyó Er ő HÁG hr ő LÉ ien ál tó eti tollak et rést re Gá a 3 dés 317 


Programtervezési minták xiii 





AIA lEKALÓNÁNT ( ed ké IAN A EPE A EGG ENG ET ÉELE E E KÁ 4 LSES Et kás 318 
EZZEL 4 3 jálée ő áj ádÖK AND ÉR KELAG 9 Ögákttk Já S itestt let al olé 18 ka ÖS ak án JE Az a geg eszt 319 
KÉBZLVEKŐMI irá ss it Ír. d été fő ds esd 1 E etés ÉS zélkae tér arárakát a ATÁAZAT b EYBŐS 1 KEMI E 319 
ÉGYÜLTŰÜKÖTÉS : Ezt t 4 va LÉSI : C dát 4 ÜNK ú 4 Út ét 46 HE TÉLLE GE NSZ 319 
BOVZLSZNÉDÉAK. eri eső teő bésőes jr a ssáte 4 € hólbi d a sitázi őr gk bee légi S gyét ől 320 
ATS ÉNT TESK ÉS eli és ete ih Brega 9. Ab herdék b AGYA JÁ Öt AAL VE HOGZ, EGÁL Ő $r zylnt a A TEPETÓ 321 
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Ajánlások 


Jó ideje nem olvastam ilyen kitűnően megírt és mélyreható könyvet... A tervezési minták 
létjogosultságát a lehető legjobb módszerrel bizonyítja: nem a magyarázat, hanem a példák 
erejével." 


Stan Lippman, Ct4 Report 


,... Gamma, Helm, Johnson és Vlissides eme új könyvének hatása a szoftvertervezés 
elméletére bizonyosan hosszan tartó lesz. Kár, hogy a Programtervezési minták maga azt 
állítja, hogy csak az objektumközpontú programokkal foglalkozik, mert így az eme 
közösségen kívüli szoftverfejlesztők esetleg kézbe sem veszik — ami nagy kár lenne, mert a 
kötet mindenkinek nyújt valamit, aki szoftvert fejleszt. Minden fejlesztő használ tervezési 
mintákat, az újrahasznosítható elvont elemek jobb megértése pedig csak jobbá teheti 
munkánkat." 


Tom DeMarco, IEEE Software 


, Összességében úgy gondolom, a könyv hozzájárulása a szakterülethez egyedülálló és 
felbecsülhetetlen. Az objektumközpontú tervezés terén szerzett hatalmas tapasztalat áll 
mögötte, melyet tömör és újrahasznosítható formában tárnak elénk. Biztos, hogy gyakran 
fogom fellapozni, ha ötletekre lesz szükségem az objektumközpontú tervezést illetően — de 
hát éppen ez az újrahasznosítás lényege, nem?" 


Sanjiv Gossain, Journal of Object-Oriented Programming 
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,Ez a régen várt könyv méltó az előzetes hírveréshez: mint egy építész tervei, úgy sora- 
koznak benne az idők során számtalanszor bizonyított, kipróbált módszerek, A szerzők az 
objektumközpontú tervezés terén szerzett több évtizedes tapasztalatukkal 23 mintát vá- 
lasztottak ki, és önmagában ez a szám mutatja, milyen alapos és fegyelmezett munkát 
végeztek. A Programtervezési minták egy példányával minden programozónak rendel- 
keznie kell, aki szeretne még jobb lenni!" 


Larry O Brien, Software Development 


Kétségtelen tény, hogy a tervezési minták teljesen megváltoztathatják a szoftverfejlesztés 
módját, és a valódi, elegáns tervezés szintjére emelhetik. A Programtervezési minták az e 
területről írott könyvek közül messze kiemelkedik: olyan könyv, amelyet el kell olvasni, a 
mélyére kell ásni, meg kell tanulni kívülről — és szeretni kell. Mindörökre megváltoztatja 
a nézőpontunkat a programokat illetően." 


Steve Billow, Journal of Object-Oriented Programming 


,A Programtervezési minták igen erőteljes könyv. Rövid ismerkedés után a legtöbb C--4- 
programozó képes lesz hasznosítani a benne bemutatott mintákat, hogy jobb programokat 
készítsen. A kötet intellektusunkat tökéletesen kielégíti: a gyakorlatban használható eszkö- 
zöket nyújt, amelyek elgondolkodtatnak és segítenek, hogy hatékonyabban fejezhessük ki 
magunkat. Alapvetően megváltoztatja, amit a programozásról gondolunk." 


Tom Gargill, Cs Report 








Bevezetés 


Ennek a könyvnek nem az a célja, hogy bevezetést adjon az objektumközpontú (objektum- 
orientál?), megoldásokhoz és az objektumközpontú programok fejlesztéséhez. A témáról 
számos igen jó könyvet írtak már. Kötetünk azt feltételezi, hogy az Olvasó jártas legalább 
egy objektumközpontú nyelvben, és rendelkezik valamennyi tapasztalattal az objektum- 
központú tervezés terén is. Vagyis a leghatározottabban nem azoknak szól, akiknek 
a szótárért kell nyúlniuk, amikor típusokról vagy többalakúságról beszélünk, vagy ha 
szembeállítjuk a felületöröklést a megvalósítás-örökléssel. 


Másrészről nem célunk az sem, hogy haladó szintű, technikai jellegű tárgyalását adjuk 
a témának. Ez csupán egy tervezési mintákat tartalmazó könyv, ami egyszerű és elegáns 
megoldásokat ír le egy-egy adott — az objektumközpontú szoftvertervezésen belüli — prob- 
lémára. A tervezési minták olyan, hosszú évek alatt kidolgozott és továbbfejlesztett megol- 
dásokat írnak le, amelyek az idők során már bizonyítottak, vagyis nem a , kezdeti ötletek" 
kategóriájába tartoznak. Többszöri újratervezés, újrakódolás áll mögöttük, amelynek célja 
a jobb újrahasznosíthatóság és a nagyobb rugalmasság volt. A tervezési minták ezeket 
a megoldásokat foglalják össze tömör, könnyen alkalmazható formában. 


A tervezési minták sem ,rejtett" nyelvi szolgáltatások, sem mások elkápráztatását szolgáló 
programozási trükkök ismeretét nem igénylik. Mindegyik megvalósítható szabványos 
objektumközpontú nyelveken, bár talán egy kicsivel több munkát igényelnek, mint az 
valkalmi" megoldások. A befektetett erőfeszítések azonban megtérülnek, ahogy prog- 
ramjaink rugalmassága és újrahasznosíthatósága nő. 


Ha egyszer megértjük a tervezési mintákat és nem csak kérdőn nézünk, amikor szóba 
kerülnek, soha többé nem fogunk az objektumközpontú tervezésre ugyanúgy gondolni. 
Ösztönösen olyan programokat fogunk készíteni, amelyek rugalmasabbak, modulári- 
sabbak és átláthatóbbak — de hát éppen ezért választottuk az objektumközpontú prog- 
ramozást, nem igaz? 
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Figyelmeztetésképpen, de egyszersmind bátorításként fel kell hívnunk a figyelmet, hogy nem 
szabad aggódni, ha nem értünk meg mindent az első olvasásra. Mi sem értettünk mindent, 
amikor először papírra vetettük... Ez a kötet nem egyszeri elolvasásra és aztán a polcra való 
— sűrűn fogjuk kézbe venni és fellapozni, hogy ötleteket gyűjtsünk a tervezéshez. 


A könyv nehezen született meg. Négy országot, három szerző házasságát, és két (rokonság- 
ban nem levő) utód születését látta, és rengeteg ember vette ki a részét a szerkesztéséből. 
Külön köszönet jár Bruce Andersonnak, Kent Becknek, és André Weinandnak biztatásukért 
és tanácsaikért. Azoknak is meg szeretnénk köszönni, akik átnézték a kézirat piszkozatát: 
Roger Bielefeld, Grady Booch, Tom Cargill, Marshall Cline, Ralph Hyre, Brian Kerninghan, 
Thomas Laliberty, Mark Lorenz, Arthur Riel, Doug Schmidt, Clovis Tondo, Steve Vinoski és 
Rebecca Wirsf-Brock — köszönjük. Hálásak vagyunk az Addison-Wesley kiadó csapatának 
(Kate Habib, Tiffany Moore, Lisa Raffaele, Pradeepa Siva és John Wait) is segítségükért, 
fáradhatatlanságukért és türelmükért, amellyel támogatták ezt a munkát. Külön köszönet Carl 
Kesslernek, Danny Sabbah-nak és Mark Wegmannak az IBM kutatóintézetéből, 


Végül, de nem utolsósorban, mindenkinek köszönetet mondunk az Internetről, akik megjegy- 
zéseket fűztek a minták különböző változataihoz, bátorító szavakat mondtak, vagy meg- 
erősítettek minket abban, hogy amit csinálunk, az értékes. Ezen emberek közé tartoznak 
(a teljesség igénye nélkül: Jon Avotins, Steve Berczuk, Julian Berdych, Matthias Bohlen, John 
Brant, Allan Clarke, Paul Chisholm, Jens Coldewey, Dave Collins, Jim Coplien, Don Dwiggins, 
Gabriele Elia, Doug Felt, Brian Foote, Denis Fortin, Ward Harold, Hermann Hueni, Nayeem 
Islam, Bikramjit Kalra, Paul Keefer, Thomas Kofler, Doug Lea, Dan LaLiberte, James Long, 
Anne Louise Luu, Pundi Madhavan, Brian Marick, Robert Martin, Dave McComb, Carl 
McConnell, Christine Mingins, Hanspeter Mössenböck, Eric Newton, Marianne Ozkan, Roxsan 
Payette, Larry Podmolik, George Radin, Sita Ramakrishnan, Russ Ramirez, Alexander Ran, Dirk 
Riehle, Bryan Rosenburg, Aamod Sane, Duri Schmidt, Robert Seidl, Xin Shu és Bill Walker. 


Nem gondoljuk, hogy a minták gyűjteménye teljes és megváltoztathatatlan; inkább csak 
a tervezésről alkotott jelenlegi gondolataink tárháza. Szívesen fogadjuk a megjegyzéseket, 
egyen az bár a példák kritikája, olyan vonatkozások és ismert felhasználási módok, 
amelyeket kihagytunk, vagy olyan tervezési minták, amelyeket bele kellett volna foglalnunk 
a könyvbe. A leveleket a gondunkat viselő Addison-Wesley kiadó fogadja, de elektronikus 
evélben, a design-patternsécs . uiuc . edu címen is elérhetők vagyunk. Ha a példa- 
kódokból elektronikus példányra lenne szükségünk, elég, ha elküldjük a ,send design 
attern source" üzenetet a design-patternsé€cs.uiuc. edu címre. A legfrissebb hírek 
és javítások a http: //st-www-cs . uic . edu/users/patterns/DPBook/DPBook . htm1 
"weboldalon érhetők el. 
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Előszó 


Minden jól szerkesztett objektumközpontú rendszer tele van mintákkal. Tulajdonképpen 
az egyik módja annak, ahogyan megítélem az objektumközpontú rendszerek minőségét az, 
hogy a tervezői vajon eléggé odafigyeltek-e az általános együttműködési lehetőségekre 
a nyelv objektumai között. Az ilyen szolgáltatásokra való összpontosítás a rendszertervezés 
folyamán olyan felépítményt eredményezhet, ami kisebb, egyszerűbb, és sokkal érthetőbb, 
mint ha ezen mintákat mellőzik. 


Az összetett rendszerek esetében a minták fontosságát már régen felismerték. Christopher 
Alexander és munkatársai voltak talán az elsők, akik felvetették egy mintanyelv hasz- 
nálatának ötletét épületek és városok építésénél. Gondolataik gyökeret vertek az objek- 
tumközpontú szoftverfejlesztők között is: röviden, a tervezési minták révén a programozás 
az építészek tudományának szintjére emelkedett. 





Ebben a könyvben Erich Gamma, Richard Helm, Ralph Johnson és John Vlissides bemu- 
tatják a tervezési minták alapelveit, majd rendszerezik is a mintákat. Így a kötet két szem- 
pontból is nélkülözhetetlen: először is, megmutatja, milyen szerepet játszhatnak a minták 
az összetett rendszerek felépítésében, másodszor, a jól felépített minták bemutatása révén 
a gyakorlatban hasznosítható kézikönyvet nyújt, amit a gyakorló tervező munkája során 
felhasználhat. 


Megtisztelve érzem magam, amiért lehetőségem volt tervezőként együtt dolgozni a könyv 
több szerzőjével is: sokat tanultam tőlük, és gyanítom, a kötetet elolvasva az Olvasó is fog. 


Grady Booch 
Vezető tudós, Rational Software Corporation 


Útmutató az olvasónak 


A kötet két fő részre oszlik. Az első rész (1. és 2. fejezeb) leírja, mik is azok a tervezési min- 
ták és hogyan segítenek objektumközpontú programokat tervezni, majd egy esettanulmány 
segítségével bemutatja, hogyan alkalmazhatók a tervezési minták a gyakorlatban. A könyv 
második része (3., 4. és 5. fejezet) a tulajdonképpeni tervezési minták katalógusa. 


E gyűjtemény teszi ki a könyv jelentős részét. A második rész fejezetei három típusra oszt- 
ják a tervezési mintákat: létrehozási, szerkezeti és viselkedési mintákra. A katalógus több- 
féle módon is használható. Elolvashatjuk az elejétől a végéig, de böngészhetünk mintáról 
mintára is. Más megközelítés, ha valamelyik fejezetet mélyrehatóan tanulmányozzuk, Ha 
ezt választjuk, látni fogjuk, hogy a közeli kapcsolatban álló minták hogyan különböztetik 
meg magukat egymástól. 


A gyűjteményben való haladáshoz logikai útirányjelzőként használhatjuk a minták közötti 
hivatkozásokat. Ez a megközelítés bepillantást enged abba, hogyan kapcsolódnak a minták 
egymáshoz, hogyan kombinálhatók más mintákkal, illetve mely minták működnek jól 
együtt. Az 1.1 táblázat grafikusan mutatja be ezeket a hivatkozási kapcsolatokat. 


Egy másik módja a katalógus elolvasásának a problémaközpontú megközelítés. Ugorjuk az 
1.6. alfejezetre, ahol néhány általános problémáról olvashatunk az újrahasznosítható objek- 
tumközpontú programtervezés területéről, majd keressük meg és tanulmányozzuk az adott 
problémákra megoldást nyújtó mintákat. Van, aki először végigolvassa a katalógust, és 
utána tér át a problémaközpontú megközelítésre, hogy megkeresse a saját munkája során 
alkalmazható mintát. 
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Ha nincs túl nagy tapasztalatunk az objektumközpontú tervezésben, kezdjük a legegysze- 
rűbb és legáltalánosabb mintákkal: 


e  Elvont gyár (Abstract Factory) 

e Illesztő (Adapter) 

s Összetétel (Composite) 

e  Díszítő (Decorator) 

e  Gyártófüggvény (Factory Method) 

e Megfigyelő (Observer) 

e Stratégia (Strategy) 

e Sablonfüggvény (Template Method) 


Olyan objektumközpontú rendszer szinte nincs is, amelyik nem használ legalább egy párat 
az itt felsorolt minták közül, a nagy rendszerek pedig csaknem mindet használják. E leg- 
gyakrabban alkalmazott minták segítenek, hogy megértsük a jó objektumközpontú terve- 
zés lényegét, illetve az egyes tervezési minták sajátosságait. 


Bevezetés 


Objektumközpontú programot tervezni nehéz, újrahasznosíthatót még nehezebb. Meg 
kell találni a megfelelő objektumokat, helyesen kell osztályokba rendezni azokat, meg kell 
határozni az osztályok felületeit és az öröklési viszonyokat, és létre kell hozni a kulcsfon- 
tosságú kapcsolatokat közöttük. A tervnek igazodnia kell az adott problémához, de eléggé 
általánosnak kell lennie ahhoz, hogy később más feladatokhoz és követelményekhez is il- 
leszthető legyen. Általában arra is törekszünk, hogy ne legyen szükség újratervezésre, vagy 
legalábbis a lehető legkisebb mértékben. Bármelyik tapasztalt tervező megmondhatja, 
hogy egy újrahasznosítható és rugalmas objektumközpontú szoftvert nagyon nehéz, ha 
nem lehetetlen elsőre pontosan megtervezni. Mielőtt egy terv kész lenne, általában több- 
ször megpróbálják újrafelhasználni, mindannyiszor módosítva rajta valamit. 


Mégis, a tapasztalt tervezők igenis készítenek jó terveket, míg a kezdő tervezők elvesznek 
a lehetőségek dzsungelében, és hajlamosak visszatérni a korábban megismert, nem objek- 
tumközpontú megoldásokhoz. Hosszú időbe telik, amíg a kezdők megtanulják, miről is 
szól a jó objektumközpontú tervezés. Vagyis a tapasztalt tervezők nyilván tudnak valamit, 
amit a tapasztalatlanok nem. De mi lehet az? 


A szakértő tervezők például tudják, hogy nem szabad minden problémára új megoldásokat 
kidolgozni. Célszerűbb újrahasznosítani azon megoldásokat, amelyek korábban már mű- 
ködőképesnek bizonyultak. Vagyis ha találunk egy jó megoldást, újra és újra felhasználhat- 
juk — ez is hozzájárul ahhoz, hogy szakértőkké válhassunk. Ebből következően a különbö- 
ző objektumközpontú rendszerekben visszatérő osztálymintákat és együttműködő objektu- 
mokat találhatunk: ezek a minták adott tervezési problémákra adnak megoldást és rugal- 
massá, elegánssá, végső soron újrahasznosíthatóvá teszik az objektumközpontú rendszere- 
ket. Segítenek a tervezőknek újrahasznosítani a sikeres terveket, azzal, hogy az új terveket 
a megelőző tapasztalat alapjaira helyezik. Az a tervező, akinek ismerősek az ilyen minták, 
rögtön képes lesz alkalmazni azokat más feladatokra is, anélkül, hogy újra fel kellene fe- 
deznie őket. 
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A lényeget egy hasonlattal ragadhatjuk meg. Regény- és színdarabírók ritkán rögtönzik 
a cselekményt; ehelyett olyan mintákat követnek, mint a , tragikusan esendő hős" (Macbeth, 
Hamlet stb.) vagy ,a romantikus regény" (erre számtalan példa akad). Hasonló módon, az 
objektumközpontú programokat készítő tervezők olyan mintákat követnek, mint az ,ábrá- 
zoljunk állapotokat objektumokkal, , készítsünk ,díszíthető" objektumokat, amelyekhez 
könnyen új jellemzőket adhatunk, vagy éppen elvehetünk belőlük". Ha ismerjük a mintát, 
számos tervezési döntés automatikusan adódik. 


Mindannyian ismerjük a tervezési tapasztalat értékét. Hányszor volt tervezés közben déja 
vu érzésünk — hogy egyszer már megoldottuk a problémát ezelőtt, de nem tudjuk, mikor és 
hogyan? Ha emlékeznénk az előző probléma részleteire és arra, hogyan oldottuk meg, újra- 
hasznosíthatnánk az akkori megoldást, ahelyett, hogy újra rá kellene jönnünk. Sajnos azon- 
ban tervezési tapasztalatainkat ritkán rögzítjük mások számára. 


E könyv célja, hogy rögzítse az objektumközpontú tervezési tapasztalatokat, tervezési min- 
tákként. Mindegyik tervezési minta rendszerez, elnevez, megmagyaráz és értékel egy fontos, 
az objektumközpontú rendszereken belül gyakran ismétlődő megoldást, Célunk az, hogy 
mások számára hatékonyan alkalmazható formában adjuk át tervezési tapasztalatainkat, 
ezért összegyűjtöttünk és leírtunk néhányat a legfontosabb tervezési minták közül 
— ezeket mutatjuk be a kötetben. 


A tervezési minták könnyebbé teszik a sikeres tervek és szerkezetek újbóli felhasználását. 
A már bizonyított módszerek tervezési mintákként való rögzítése elérhetőbbé teszi e meg- 
oldásokat az új rendszerek tervezői számára. A tervezési minták segítenek kiválasztani azt 
a megoldást, amelyik újrahasznosíthatóvá teszi a rendszert, és segítenek elkerülni azokat, 
amelyek nem. A tervezési minták a létező rendszerek dokumentálását és karbantartását is 
segíthetik, azzal, hogy pontosan leírják a mögöttük megbúvó osztályokat és objektumkap- 
csolatokat. Hogy egyszerűen fogalmazzunk, a tervezési minták segítenek a tervezőnek, 
hogy hamarabb leljen rá a helyes útra. 


Az e könyvben szereplő tervezési minták egyike sem ír le új vagy nem bizonyított terveket. 
Csak olyanokat vettünk bele, amelyeket már többször is alkalmaztak különböző rendsze- 
rekben. E tervek legtöbbjét még sohasem dokumentálták: az objektumközpontú közösség 
,folklórjának" részei csupán, vagy elemei egy sikeres objektumközpontú rendszernek, de 
egy kezdőnek ezek egyikéből sem egyszerű tanulni, Tehát, bár ezek a tervek nem újak, új 
és elérhető formában, egyfajta tervezésiminta-katalógusként tárjuk az olvasók elé. 


A könyv mérete ellenére csak a töredékét képes bemutatni egy szakember valószínűsíthető 
tudásának. Nincs benne egyetlen minta sem, ami az egyidejű (párhuzamos vagy elosztot?) 
vagy a valósidejű programozással foglalkozik, és nincsenek benne kifejezetten egy adott al- 
kalmazástípusra vonatkozó minták. Nem mondja meg, hogyan készítsünk felhasználói felü- 
leteket, hogyan írjunk meghajtóprogramokat, vagy hogyan használjunk objektumközpontú 
adatbázisokat. Természetesen ezen területek mindegyikének is megvannak a saját mintái, és 
érdemes lenne valakinek ezeket is katalogizálni. 
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1.1 Mi is az a tervezési minta? 


Christopher Alexander azt mondja: , Minden minta olyan problémát ír le, ami újra és újra fel- 
bukkan a környezetünkben, s aztán leírja hozzá a megoldás magját, oly módon, hogy 
a megoldás milliószor felhasználható legyen, anélkül, hogy valaha is kétszer ugyanúgy csi- 
nálnánk." (AIS--77, xc. oldal] Bár Alexander épületek és városok mintáiról beszélt, amit mond, 
az igaz az objektumközpontú tervezési mintákra is. A mi megoldásaink falak és ajtók helyett 
objektumok és felületek szintjén fejeződnek ki, de alapjában véve mind a kettő megoldás 
egy adott problémára az összefüggéseiben nézve. 


A mintáknak általában négy lényeges elemük van: 


1. A minta neve hivatkozási eszköz, amit arra használhatunk, hogy egy-két szóval leír- 
junk egy tervezési problémát, megoldásait és a következményeket. A minta elneve- 
zése azonnal növeli tervezési szókincsünket és lehetővé teszi, hogy magasabb elvo- 
natkoztatási szinten tervezzünk. Az, hogy vannak szavaink a mintákra, lehetővé te- 
szi, hogy beszéljük róluk a kollégáinkkal (vagy akár ,magunkkal"), és használjuk 
őket a dokumentációban. Könnyebbé teszi, hogy gondolkodjunk a tervezésről, hogy 
beszéljünk a tervekről és használatuk pozitív és negatív oldalairól. A jó nevek megta- 
lálása gyűjteményünk összeállításának egyik legnehezebb része volt. 

2. A probléma írja le, mikor alkalmazzuk a mintát, vagyis elmagyarázza a problémát és 
összefüggéseit. Leírhat konkrét tervezési problémákat is, mint például , hogyan ábrá- 
zoljunk algoritmusokat objektumokként", de olyan osztály- vagy objektumszerkeze- 
teket is, amelyek rugalmatlan tervezésre utalnak. A probléma néha feltételek listáját 
is tartalmazhatja, amelyeknek teljesülniük kell, mielőtt értelme lenne alkalmazni 
a mintát. 

3. A megoldás azokat az elemeket írja le viszonyaikkal, hatáskörükkel és együttműkö- 
dési lehetőségeikkel együtt, amelyek felépítik a tervet. Nem konkrét tervet vagy 
megvalósítást ad meg, mivel a minta olyan, mint egy sablon, ami különféle helyze- 
tekben alkalmazható. Helyette csupán egy tervezési probléma elvont leírását bizto- 
sítja, és hogy az elemek (esetünkben osztályok és objektumok) általános elrendezé- 
se hogyan oldja azt meg. 

4. A következmények a minta alkalmazásának előnyei, illetve hátrányai. Bár a következmé- 
nyekről ritkán esik szó a tervezési döntések indoklásánál, mégis létfontosságúak a ter- 
vezési alternatívák értékelésénél és annak megértésében, hogy mi a haszna és mi 
a hátránya a minta alkalmazásának. A ,következmények" gyakran a tárhely- és idő-fel- 
használást érintő hátrányokra vonatkoznak, de érinthetnek nyelvi és megvalósítási 
kérdéseket is. Miután az újrahasznosíthatóság gyakran fontos tényező az objektum- 
központú tervezésnél, a következmények hasznos információkat szolgáltatnak a rend- 
szer rugalmasságáról, bővíthetőségéről vagy hordozhatóságáról. A következmények 
felsorolása határozottan segít megérteni és értékelni az előnyöket és hátrányokat. 


Nézőpontunk határozza meg, mit tekintünk mintának és mit nem. Ami az egyiknek minta, 
a másiknak csupán elemi építőkocka; a kötetben ezért igyekeztünk a mintákra az elvonat- 
koztatás egy bizonyos szintjén összpontosítani. A Programtervezési minták nem az olyan 
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szerkezetekről szól, mint a láncolt listák vagy a hasítótáblák (kivonatok), amelyeket osztá- 
lyokként kódolhatunk és így újra felhasználhatunk, de nem is összetett, teljes alkalmazá- 
sok vagy alrendszerek építéséhez használható tervezetekről. A könyvben bemutatott ter- 
vezési minták egymással együttműködő objektumok és osztályok leírásai, amelyek 
testreszabott formában valamilyen általános tervezési problémát oldanak meg egy bizo- 
nyos összefüggésben. 


A tervezési minták megnevezik, elvonatkoztatják és azonosítják egy-egy mindennapos 
szerkezet kulcsfontosságú tulajdonságait, amelyek lehetővé teszik, hogy újrahasznosítható 
objektumközpontú tervet állítsunk elő. A tervezési minta azonosítja a részt vevő osztályo- 
kat és példányokat, szerepüket és kapcsolataikat, illetve a felelősségi körök eloszlását. 
Mindegyik tervezési minta egy bizonyos objektumközpontú tervezési kérdésre összponto- 
sít. Leírja, mikor alkalmazható, más tervezési megszorításokat figyelembe véve lehet-e al- 
kalmazni, továbbá ismerteti használatának következményeit és az előnyöket, illetve hátrá- 
nyokat. Mivel a terveket előbb-utóbb meg is kell valósítanunk, a minták mellett példákat is 
nyújtunk Ct--- és (időnként) Smalltalk nyelven, hogy illusztráljuk a megvalósítás módját. 


Bár a tervezési minták objektumközpontú szerkezeteket írnak le, gyakorlati megoldásokon 
alapulnak, amelyeket az olyan általános objektumközpontú programozási nyelvek, mint 
a Smalltalk és a C---- beépítve tartalmaznak, szemben az eljárásközpontú (procedurális) nyel- 
vekkel (Pascal, C, Ada) vagy a dinamikusabb objektumközpontú nyelvekkel (CLOS, Dylan, 
Self. Gyakorlati okok miatt választottuk a Smalltalkot és a C--4--t: népszerűségük állandó, és 
mindennapos tapasztalataink vannak velük. 


A programnyelv választása fontos, mivel befolyásolja a programozó nézőpontját. A mi min- 
táink Smalltalk, illetve C-- szintű nyelvi tulajdonságokat feltételeznek, és ez a választás 
meghatározza, mit lehet és mit nem lehet könnyen megvalósítani. Ha eljárásközpontú nyel- 
veket feltételeztünk volna, a kötetbe a következő nevű mintákat is bele kellett volna foglal- 
nunk: Öröklés", , Betokozás (egységbe zárás)" , Többalakúság?" stb. Néhány mintánkat vi- 
szont közvetlenül támogatja egy-egy kevésbé mindennapi objektumközpontú programozási 
nyelv. A CLOS-nak például vannak úgynevezett multi-metódusai, amelyek csökkentik az 
igényt az olyan mintákra, mint a Látogató (Visitor). Persze számos különbség van a Smalltalk 
és a Cst között is, ami annyit tesz, hogy néhány minta könnyebben kifejezhető az egyik 
nyelven, mint a másikon: ilyen például a Bejáró (Iterator). 


1.2 Tervezési minták a Smalltalk MVC-ben 


A Model-View-Controller (MVOC) osztályhármas [KP88] arra használatos, hogy felhasználói 
felületeket építsünk fel a Smalltalk-80-ban. Az MVC-n belüli tervezési mintákra pillantva 
jobban megérthetjük, mit értünk a , minta" kifejezés alatt. 


Az MVC háromfajta objektumot tartalmaz. A Model (Modell) az alkalmazás objektum, a View 
(Néze0) annak ábrázolása a képernyőn, a Controller (Vezérlő) pedig annak módját határozza 
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meg, ahogyan a felhasználói felület válaszol a felhasználói bemenetre. Az MVC előtt a fel- 
használói felületek tervezésekor hajlamosak voltak ezeket az objektumokat egymásba olvasz- 
tani, Az MVC szétválasztja őket, hogy növelje a rugalmasságot és az újrahasznosíthatóságot. 


Az MVC úgy választja szét a nézeteket és modelleket, hogy egy előfizetés-értesítés proto- 
kollt hoz létre közöttük. A nézetnek gondoskodnia kell arról, hogy megjelenése tükrözze 
a modell állapotát. Valahányszor a modell adatai megváltoznak, a modell értesíti azokat 
a nézeteket, amelyek rá támaszkodnak, azok pedig lehetőséget kapnak rá, hogy frissítsék 
magukat. Ez a megközelítés lehetővé teszi, hogy többféle nézetet kapcsoljunk egy modell- 
hez, hogy különböző megjelenítéseket biztosítsunk, emellett pedig anélkül készíthetünk új 
nézeteket a modellhez, hogy újraírnánk azt. 


A következő diagram egy modellt és három nézetet mutat. (Az egyszerűség kedvéért ki- 
hagytuk a vezérlőket.) A modell néhány adatértéket tartalmaz, a nézetek pedig egy tábláza- 
tot, egy hisztogramot és egy tortadiagramot határoznak meg, amelyek ezeket az adatokat 
jelenítik meg különféle módokon. 


A modell értesíti a nézeteket, amikor az értékei megváltoznak, a nézetek pedig kapcsolatot 
tartanak a modellel, hogy elérjék ezeket az értékeket. 


Nézetek 
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modell 


Felszínesen értékelve, ez a példa egy olyan szerkezetet tükröz, ami elválasztja a nézeteket 
és a modellt, de alkalmazható egy jóval általánosabb problémára is: objektumok elválasztá- 
sára. Így az egy objektumot érintő változások több másikra kihathatnak, anélkül, hogy 
a megváltozott objektum ismerné a többiek belső szerkezetét. Ezt az általánosabb szerke- 
zetet írja le a Megfigyelő (Observer) tervezési minta. 
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Egy másik tulajdonsága az MVC-nek, hogy a nézetek beágyazhatók. Például egy gombokból 
álló vezérlőpult megvalósítható összetett nézetként, ami beágyazott gombnézeteket tartal- 
maz. Egy objektumvizsgáló felhasználói felülete szintén állhat beágyazott nézeteki ből, ame- 
lyeket újra felhasználhatunk egy hibakeresőben. Az MVC a CompositeView (Összetett né- 
zet) osztállyal támogatja a beágyazott nézeteket, amely a View alosztálya. A CompositeView 
objektumok úgy viselkednek, mint a View objektumok; egy összetett nézet bárhol használ- 
ható, ahol egy sima nézet (view), de ezen felül tartalmazza és kezeli a beágyazott nézeteket, 
Mindezt tekinthetjük úgy, mint egy olyan szerkezetet, ami lehetővé teszi számuni kra, hogy 
az összetett nézetek egészét ugyanúgy kezeljük, mint az egyes elemeiket, de ismét csak azt 
mondhatjuk, hogy a terv egy ennél jóval általánosabb problémára is alkalmazható, ami 
mindig felbukkan, valahányszor csoportba akarunk foglalni objektumokat és úgy kezelni 
ezen csoportot, mint egy egységes objektumot. Ezt az általánosabb szerkezetet a Összetétel 
(Composite) tervezési minta írja le, Segítségével osztályhierarchiát hozhatunk létre, amely- 
ben egyes alosztályok elemi objektumokat írnak le (pl. Gomb), más osztályok pedig össze- 
tett objektumokat (CompositeView), amelyek az elemi objektumokból állnak össze. 





Az MVC azt is lehetővé teszi, hogy megváltoztassuk azt, ahogyan a nézet reagál a felhasználói 
bemenetre, anélkül, hogy módosítanánk a megjelenését, Például lehet, hogy változtatni sze- 
retnénk azon, ahogyan a billentyűleütésekre reagál, vagy helyi előugró menüt szeretnénk 
használni billentyűparancsok helyett. Az MVC a válaszrendszert egy vezérlő (Controller) ob- 
jektumba zárja; e vezérlők pedig osztályhierarchiát alkotnak, megkönnyítve az új vezérlők 
készítését a már létezők alapján. 


A nézetek valamelyik Controller alosztály egy példányát használják, hogy megvalósítsák a kí- 
vánt válaszstratégiát; eltérő reagálás megvalósításához egyszerűen lecseréljük a példányt egy 
másfajta vezérlőre. Az is lehetséges, hogy futásidőben változtassuk meg a nézet vezérlőjét, így 
lehetővé tehetjük a nézet számára, hogy a felhasználói bemenetre másképpen válaszoljon. 
Egy nézet például letiltható egyszerűen úgy, hogy olyan vezérlőhöz rendeljük, amely nem 
veszi figyelembe a bemeneti eseményeket, így a nézet nem fogadja el a bemeneteket. 


A nézet-vezérlő viszony a Stratégia (Strategy) tervezési minta példája. A stratégia egy ob- 
jektum, ami egy algoritmust képvisel. Akkor vesszük hasznát, amikor statikusan vagy dina- 
mikusan ki akarjuk cserélni az algoritmust, amikor az algoritmusnak számos változatával 
rendelkezünk, vagy amikor az algoritmusnak összetett adatszerkezetei vannak, amelyeket 
egységbe szeretnénk zárni. 


Az MVC más tervezési mintákat is használ, például a Gyártófüggvényt (Factory Method), hogy 
megadja az alapértelmezett vezérlőosztályt egy nézet számára, vagy a Díszítő (Decorator) min- 
tát, hogy gördítősávot adjon egy nézethez, de a fő összefüggéseket az MVC-ben a Megfigyelő, 
az Összetétel és a Stratégia tervezési minták adják meg. 
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1.3 A tervezési minták leírása 


Hogyan írunk le tervezési mintákat? A grafikus jelölésmódok, habár fontosak és hasznosak, 
nem elegendőek, hiszen csak a tervezési folyamat végterméket mutatják, az osztályok és ob- 
jektumok viszonyaként. Ahhoz, hogy újrahasznosíthassuk a tervet, muszáj rögzítenünk 
a döntéseket, az alternatívákat és döntéseink következényeit is. A konkrét példák is fonto- 
sak, mivel segítenek abban, hogy a tervet működés közben lássuk. 


A könyvben a tervezési mintákat egységes formában írtuk le. Mindegyik mintát szakaszok- 
ra osztottuk, amelyek a következő sablonhoz igazodnak. A sablon egységes szerkezetet 
kölcsönöz az információknak, egyszerűbbé téve a tervezési minták megtanulását, összeha- 
sonlítását és használatát. 


A minta neve és besorolása 
A minta neve a minta lényegét közvetíti rövid formában. A jó név létfontosságú, mi- 
vel a tervezési szókincs részévé válik. A minta besorolásának alapját az 1.5 részben 
található vázlat adja meg. 
Cél 
Rövid leírás, amely a következő kérdésekkel foglalkozik: Mit csinál az adott tervezé- 
si minta? Mi az értelme és a célja? Milyen sajátos tervezési problémára ad választ? 
Egyéb nevek 
A minta más, jól ismert nevei, ha vannak ilyenek, illetve a minta angol neve. 
Feladat 
Forgatókönyv, amely bemutatja a tervezési problémát és azt, hogy az osztályok és az 
objektumok hogyan oldják azt meg. A forgatókönyv segít a minta következő, elvon- 
tabb leírásának megértésében. 
Alkalmazhatóság 
Melyek azok a helyzetek, ahol az adott tervezési minta alkalmazható? Melyek azok 
a rossz tervek, amelyek leváltását a minta megcélozza? Hogyan ismerhetők fel ezek? 
Szerkezet 
A minta osztályainak grafikus szemléltetése, az OMT-n (Object Modeling Technigue 
ÍRPB--91]) alapuló jelölést használva. Együttműködési diagramokat (, interakció-di- 
agramokat") is használunk [JCJO92, Boo94l, hogy szemléltessük a kérelmek és 
együttműködések sorozatát az objektumok között. A jelölésrendszert részletesen a B 
függelék ismerteti. 
Résztvevők 
Az osztályok, illetve objektumok, amelyek részt vesznek a tervezési mintákban, vala- 
mint azok feladatai. 
Együttműködés 
Hogyan működnek együtt az objektumok, hogy végrehajtsák feladataikat? 
Következmények 
Hogyan támogatja az adott minta a kívánt célokat? Mik a minta használatának elő- 
nyei és hátrányai? A rendszer mely szerkezeti elemeit változtathatjuk szabadon az 
adott mintát használva? 
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Megvalósítás 
Milyen buktatókra kell ügyelni, milyen módszereket érdemes használni a minta 
megvalósításakor? Vannak nyelvi sajátosságok? 

Példakód 
Programkód-töredékek, amelyek illusztrálják, hogyan valósítható meg a minta C--t 
vagy Smalltalk nyelven. 

Ismert felhasználások 
Valós rendszerekből vett példák a mintára. Legalább két példát szerepeltetünk, kü- 
lönböző területekről. 

Kapcsolódó minták 
Mely tervezési minták kapcsolódnak szorosan az adott mintához? Mik a legfonto- 
sabb különbségek? Milyen más mintákkal együtt célszerű használni az adott mintát? 


A függelékekben kiegészítő információkat találhatunk, amelyek segítenek megérteni a min- 
tákat és a hozzájuk kapcsolódó magyarázó leírásokat. Az A függelék az általunk használt 
szakkifejezések jegyzéke. Már említettük a B függeléket, ami a különféle jelöléseket mutatja 
be. Végezetül, a C függelék azon alaposztályok forráskódját tartalmazza, melyeket a példa- 
kódokban használtunk. 


1.4 A tervezési minták katalógusa 


Gyűjteményünk 23 tervezési mintát tartalmaz. Ezek neve és célja áttekintésképpen a követ- 
kező listában szerepel. 


Elvont gyár (Abstract Factory) Kapcsolódó vagy egymástól függő objektumok családjá- 
nak létrehozására szolgáló felületet biztosít a konkrét osztályok megadása nélkül. 
Illesztő (Adapter) Az adott osztály felületét az ügyfelek által igényelt felületté alakítja. 
E módszerrel az egyébként összeférhetetlen felületű osztályok együttműködését biz- 

tosíthatjuk. 

Híd (Bridge) Az elvont ábrázolást elválasztja a megvalósítástól, hogy a kettő egymástól 
függetlenül módosítható legyen. 

Építő (Builder) Az összetett objektumok felépítését függetleníti az ábrázolásuktól, így 
ugyanazzal az építési folyamattal különböző ábrázolásokat hozhatunk létre. 

Felelősséglánc (Chain of Responsibility) Arra szolgál, hogy elkerüljük a kérelem küldőjé- 
nek a fogadóhoz való kötését. Ezt úgy érjük el, hogy több objektumnak is jogot 
adunk a kérelem kezelésére. A fogadó objektumokat láncba állítjuk, amelyen a kére- 
lem addig halad, amíg el nem ér egy objektumot, ami képes a kezelésére. 

Parancs (Command) A kérelmeket objektumba zárja, aminek célja, hogy az ügyfeleknek 
paraméterként különböző kérelmeket adjunk át, ezeket sorba állítsuk vagy naplóz- 
zuk, illetve támogassuk a műveletek visszavonását. 

Összetétel (Composite) Az objektumokat faszerkezetbe rendezi, hogy ábrázolhassuk 
a rész-egész viszonyokat. A módszer révén az önálló objektumokat és az objek- 
tumösszetételeket egységesen kezelhetjük. 
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Díszítő (Decorator) Az objektumokhoz dinamikusan további felelősségi köröket rendel. 
A kiegészítő szolgáltatások biztosítása terén e módszer rugalmas alternatívája az al- 
osztályok létrehozásának. 

Homlokzat (Facade) Egy alrendszerben felületek egy halmazához egységes felületet biz- 
tosít. A módszerrel magasabb szintű felületet határozunk meg, amelynek révén az 
adott alrendszer könnyebben használhatóvá válik. 

Gyártófüggvény (Factory Method)  Felületet határoz meg egy objektum létrehozásához, de 
az alosztályokra bízza, melyik osztályt példányosítják. A gyártófüggvények megen- 
gedik az osztályoknak, hogy a példányosítást az alosztályokra ruházzák át. 

Pehelysúlyú (Flyweight) . Megosztás révén támogatja a nagy finomságú objektumok töme- 
geinek hatékony felhasználását. 

Értelmező (Interpreter) Egy adott nyelv nyelvtanát ábrázolja, illetve ehhez az ábrázoláshoz 
értelmezőt biztosít, amely annak alapján képes az adott nyelv mondatait megérteni. 

Bejáró (lterator) Az összetett objektumok elemeinek soros elérését a háttérben megbú- 
vó ábrázolás felfedése nélkül biztosító módszer. 

Közvetítő (Mediator) Egy objektumot határoz meg, amely objektumok egy halmazának 
együttműködését irányítja. (Vagyis ezeket egyetlen objektumba tokozzuk be.) A mód- 
szerrel laza csatolást hozunk létre, amelyben az egyes objektumok közvetlenül nem 
hivatkozhatnak egymásra, a köztük levő kapcsolatok pedig egymástól függetlenül 
módosíthatók. 

Emlékeztető (Memento) Az egységbe zárás (betokozás, enkapszuláció) megsértése nél- 
kül kinyeri és rögzíti egy objektum belső állapotát, hogy az később ebbe az állapot- 
ba visszaállítható legyen. 

Megfigyelő (Observer) . Objektumok között egy-sok függőségi kapcsolatot hoz létre, így 
amikor az egyik objektum állapota megváltozik, minden tőle függő objektum értesül 
erről és automatikusan frissül. 

Prototípus (Prototype)  Prototípus példány használatával meghatározza, milyen típusú 
objektumokat kell létrehozni, az új objektumok létrehozását pedig ennek a prototí- 
pusnak a lemásolásával állítja elő. 

Helyettes (Proxy) Adott objektumot képviselőn vagy helyőrzőn keresztül irányítunk, 
hogy szorosabban felügyelhessük működését. 

Egyke (Singleton) Egy osztályból csak egy példányt engedélyez, és ehhez globális hoz- 
záférési pontot ad meg. 

Állapot (State) Adott objektum számára engedélyezi, hogy belső állapotának megválto- 
zásával megváltoztathassa viselkedését is. Az objektum ekkor látszólag módosítja az 
osztályát. 

Stratégia (Strategy)  Algoritmus-családot határoz meg, melyben az algoritmusokat 
egyenként egységbe zárjuk és egymással felcserélhetővé tesszük. E módszer révén 
az algoritmus a felhasználó ügyféltől függetlenül módosítható. 

Sablonfüggvény (Template Method) " Adott művelet algoritmusának vázát készíti el, amely- 
nek egyes lépéseit alosztályokra ruházza át. Így az alosztályok az algoritmus egyes 
lépéseit felülbírálhatják, anélkül, hogy az algoritmus szerkezete módosulna. 
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Látogató (Visitor) . Objektumszerkezet elemein végrehajtandó műveletet ábrázol: a Láto- 
gató minta segítségével anélkül határozhatunk meg egy új műveletet, hogy a benne 
részt vevő elemek osztályát meg kellene változtatnunk. 


1.5 A katalógus rendszerezése 


A tervezési minták részletességükben és elvonatkoztatási szintjük szerint különbözőek. Mi- 
vel sok tervezési minta van, szükséges őket valamilyen úton-módon rendszerezni. Ebben 
a részben osztályokba soroljuk a tervezési mintákat, így hivatkozhatunk a rokon minták 
családjaira. Az osztályba sorolás segíti a katalógusban levő minták gyorsabb megtanulását 
és új minták felfedezésére is ösztönözhet. 
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1.1 táblázat 
Tervezési minták hatókör szerint. 


A tervezési mintákat két szempont szerint osztályozhatjuk (1.1 táblázaD. Az első a cél, ami 
azt tükrözi, mit csinál a minta. A mintáknak létrehozási, szerkezeti vagy viselkedési célja lehet. 
A létrehozási minták (vagy alkotó minták) az objektum-létrehozás folyamatában érdekel- 
tek. A szerkezeti minták az objektumok és osztályok felépítésével foglalkoznak. A viselke- 
dési minták azon tulajdonságokat írják le, ahogyan az objektumok kölcsönösen együttmű- 
ködnek és felosztják a felelősségi köröket. 
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A második szempont a hatókör, ami meghatározza, hogy a minta objektumra vagy osztályra 
alkalmazható-e, Az osztályminták az osztályok és az alosztályok viszonyával foglakoznak. 
Ezen viszonyok örökléssel létesítődnek, ezért statikusak, vagyis fordításkor rögzítettek. 
Az objektumminták objektumkapcsolatokra vonatkoznak, amelyek futásidőben megváltoz- 
tathatók, ezért jóval dinamikusabbak. Majdnem minden minta használ valamilyen szintű 
öröklést, így csak azokat a mintákat hívjuk , osztálymintáknak", amelyek az osztályok kö- 
zötti viszonyokra összpontosítanak. A legtöbb minta az , objektum" hatókörbe tartozik. 


A létrehozási osztályminták az objektum-létrehozás feladatát részben az alosztályokra ru- 
házzák át, míg a létrehozási objektumminták egy másik objektumra hagyják. A szerkezeti 
osztályminták öröklést használnak az osztályok előállításához, míg a szerkezeti objektum- 
minták objektumépítési módokat írnak le. A viselkedési osztályminták öröklést használnak 
az algoritmusok és vezérlési folyamatok leírásához, míg a viselkedési objektumminták azt 
írják le, hogyan dolgozik együtt objektumok egy csoportja, hogy végrehajtsanak egy olyan 
feladatot, amelyet egyetlen objektum nem tudna önmagában végrehajtani. 





A minták csoportosításának két másik módja lehet. Néhány mintát gyakran együtt haszná- 
lunk: ilyen például az Összetétel, amelyet gyakran használunk együtt a Bejáró és a Látogató 
mintákkal. Néhány minta vagylagos: a Prototípus mintát például gyakran az Elvont gyár he- 
lyett használhatjuk. Néhány minta hasonló felépítést eredményez, holott más-más célt szol- 
gálnak: például az Összetétel és a Díszítő minták szerkezeti diagramjai egyformák. 


A tervezési minták rendszerezésének másik módja, amikor aszerint csoportosítjuk őket, 
hogy a , Kapcsolódó minták" leírásban mely más mintákra hivatkoznak. Az 1.1 ábra ezeket 
a viszonyokat festi le grafikusan. 


Nyilvánvalóan sokféle módon csoportosíthatjuk még a tervezési mintákat, és a több szinten 
való gondolkodás elmélyítheti rálátásunkat arra, hogy mit csinálnak, miben hasonlítanak 
egymásra, és mikor kell alkalmazni őket. 


1.6 Hogyan oldják meg a tervezési minták a tervezési problémákat? 


A tervezési minták számos olyan mindennapos problémát oldanak meg, amelyekkel a ter- 
vezők szembetalálkoznak, méghozzá sokféleképp. Alább felsoroltunk párat ezen problé- 
mák közül, és leírtuk, hogyan oldják meg ezeket a tervezési minták. 


Megfelelő objektumok keresése 

Az objektumközpontú programok objektumokból épülnek fel. Az objektumok magukba fog- 
lalják mind az adatokat, mind az adatokon dolgozó eljárásokat, amelyeket (tag)függvé- 
nyeknek, metódusoknak, vagy műveleteknek hívunk. Az objektum akkor hajt végre egy mű- 
veletet, ha az ügyféltől kérelem (vagy üzenet) érkezik. 
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Egy objektum kizárólag akkor hajthat végre műveletet, ha kérelem érkezik hozzá, belső 
adatai pedig kizárólag műveletekkel változtathatók meg. Ezek miatt a megszorítások miatt 
az objektum belső állapota egységbe van zárva, vagyis nem érhető el közvetlenül, és az ob- 
jektumon kívülről láthatatlan. 


Az objektumközpontú tervezés nehézsége az adott rendszer objektumokra való felbontásában 
rejlik. A feladat azért nehéz, mert sok tényező jön számításba: az egységbe zárás (betokozás), 
a finomság" (részletesség, ,szemcsézettség"), a függőségek, a rugalmasság, a teljesítmény, 
a továbbfejleszthetőség, az újrahasznosíthatóság és így tovább. Ezek mind befolyásolják a fel- 
bontást, sokszor egymásnak ellent mondva. 


Az objektumközpontú tervezés módszertana számos megközelítést támogat. Az egyik, 
hogy körülírjuk a feladatot, majd főneveket és igéket társítunk hozzá, végül ezek segítségé- 
vel megalkotjuk a megfelelő osztályokat és műveleteket. De helyezhetjük a hangsúlyt 
a rendszer elemeinek együttműködésére és a felelősségi körökre is. Vagy modellezhetjük 
a valódi világot, és az annak elemzése közben , talált" objektumokat foglalhatjuk rendszer- 
be. Arról, hogy melyik megközelítés a legjobb, valószínűleg mindig vita fog folyni. 





A tervezés során számos objektumot az elemző modellből származtatunk, de az objektum- 
központú rendszerekben végül gyakran olyan osztályok szerepelnek, amelyeknek a valódi 
világban nincs megfelelőjük. Ezek egy része alsó szintű osztály, amilyen például a tömb. 
Mások sokkal magasabb szintűek. Az Összetétel minta például egy olyan elvont rendszert ír 
le, amelyben fizikai megfelelővel nem rendelkező objektumokat kezelhetünk egységesen. 
A valódi világ szigorú modellezése olyan rendszerhez vezet, ami ugyan bemutatja a ma va- 
lóságát, de a holnapét már nem feltétlenül. A tervezés során felmerülő elvont fogalmak 
( absztrakciók") kulcsfontosságúak a terv rugalmassága szempontjából. 


A tervezési minták segítenek a kevésbé egyértelmű fogalmak és az azokat ábrázoló objek- 
tumok felismerésében. Például azok az objektumok, amelyek folyamatokat vagy algoritmu- 
sokat képviselnek, a természetben nem fordulnak elő, mégis fontos részei a rugalmas min- 
táknak. A Stratégia minta azt írja le, hogyan valósítsunk meg felcserélhető algoritmuscsalá- 
dokat. Az Állapot minta egy adott egyed összes állapotát objektumként ábrázolja. Ezek az 
objektumok ritkán találhatók meg a valóság elemzésével vagy a tervezés korai szakaszá- 
ban; később kerülnek napfényre, amikor a tervet igyekszünk rugalmasabbá és újrahaszno- 
síthatóbbá tenni. 


A szükséges objektumok megkeresése 

Az objektumok mérete és száma a különböző rendszerekben nagyfokú eltérést mutathat. 
Képviselhetnek mindent, egészen a hardvereszközökig, de átfoghatnak nagyobb egysége- 
ketis, a teljes alkalmazások szintjéig. Hogyan döntsük el, hogy mi is legyen egy objektum? 


A tervezési minták erre a kérdésre is választ adnak. A Homlokzat minta azt írja le, hogyan 
ábrázoljunk objektumokként egész alrendszereket, míg a Pehelysúlyú minta azt, hogy ho- 
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stratégiák Értelmező hozzáadása Felelősséglánc 
megosztása 
terminál- 
"5 szimbólu- 
Stratégia állapotok mok meg- - 
megosztása osztása Közvetítő 
összetett füg- 
gőségkezelés 1 Megfigyelő 
algoritmus Állapot 
lépéseinek 
gyakran ezt 
meghatározása 1 ú 
7 Sablonfüggvény használja 
Prototípus fu 
dinamikus Gyártófüggvény 
gyárbeállítás megvalósítás ennek 
használatával 
Elvont gyár 
egyetlen 
példány 
egyetlen Homlokzat 
példány 
Egyke 





1.1 ábra 
Tervezésiminta-kapcsolatok. 
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gyan támogassunk nagyon sok, ,nagy finomságú" (kis részleteket leíró) objektumot. Más 
tervezési minták különböző módokat írnak le az objektumok kisebb objektumokra való 
szétbontására. Az Elvont gyár és az Építő minták olyan objektumokat eredményeznek, 
amelyeknek egyetlen feladata más objektumok létrehozása, a Látogató és a Parancs minták 
pedig olyanokat, amelyek egyetlen célja kérelmeket intézni objektumokhoz vagy objek- 
tumcsoportokhoz. 


Az objektumfelületek meghatározása 

Minden objektum által leírt művelet megadja a művelet nevét, az objektumokat, amiket pa- 
raméterként kap, és a művelet visszatérési értékét. Ezt hívjuk a művelet aláírásának ( szigna- 
túra"). Az objektum műveletei által meghatározott összes ilyen aláírás halmaza az objektum 
felülete. A felület jellemzi az objektumnak küldhető kérelmek teljes halmazát. Bármely, az 


objektum felületében lévő aláírásnak megfelelő kérelem elküldhető az objektumnak. 


A típus egy név, ami egy bizonyos felületet jelent. Azt mondjuk, hogy egy objektum , ablak" 
típusú, ha az ,ablak" nevű felületben értelmezett műveleteknek címzett kérést fogad, Egy 
objektumnak több típusa is lehet, és sokban különböző objektumok is osztozhatnak egy tí- 
puson. Az objektum felületének egy részét egy típus jellemezheti, míg a többit más típusok. 
Két azonos típusú objektumnak csak felületük egy részében kell egyeznie. A felületek más 
felületeket is tartalmazhatnak részhalmazként. Egy típus akkor altípusa egy másiknak, ha 
a felülete tartalmazza az őstípus felületét, Sokszor úgy mondjuk, hogy az altípus örökli az 
őstípus felületét. 


A felületek alapvető fontosságúak az objektumközpontú rendszerekben. Az objektumokat 
csak a felületeiken keresztül ismerjük. Nincs rá mód, hogy bármit is megtudjunk egy objek- 
tumról, vagy megkérjük, hogy tegyen valamit, anélkül, hogy a felületén át ne haladnánk. 
Az objektum felülete semmit nem mond a megvalósításáról — a különböző objektumok kü- 
lönböző módokon teljesíthetik a kéréseket. Vagyis két objektum, amelynek teljesen más 
a megvalósítása, felületében teljesen megegyezhet. 


Ha egy objektumnak kérelmet küldünk, a művelet, ami végrehajtódik, függ mind a kére- 
lemtől, mind a fogadó (vevő) objektumtól. Különböző objektumok, amelyek ugyanolyan 
kéréseket támogatnak, különbözhetnek az ezeket végrehajtó műveletek megvalósításában. 
A kérelmek objektumokhoz és azoknak egy műveletéhez való futásidőben történő hozzá- 
rendelését dinamikus kötésnek vagy késői kötésnek nevezzük. 


A késői kötés azt jelenti, hogy egy kérelem kiadása nem határozza meg a konkrét megvaló- 
sítást, egészen a program futásáig. Következésképp írhatunk olyan programokat, amelyek 
egy bizonyos felülettel rendelkező objektumot várnak, tudván, hogy bármelyik olyan ob- 
jektum elfogadja majd a kérelmet, amelynek megfelelő a felülete. A késői kötés emellett 
megengedi, hogy egyforma felülettel rendelkező objektumokat futásidőben egymással he- 
lyettesítsünk. Ennek a helyettesíthetőségnek a neve többalakúság (polimorfizmus), és kulcs- 
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fontosságú elv az objektumközpontú rendszerekben. Leszűkíti a feltételezések körét, amit 
az ügyfélobjektumnak más objektumokról tennie kell azon kívül, hogy támogatják az adott 
felületet. A többalakúság leegyszerűsíti az ügyfelek meghatározását, szétválasztja az objek- 
tumokat, és lehetővé teszi, hogy azok kapcsolata futásidőben módosuljon. 


A tervezési minták azzal segítenek a felületek meghatározásában, hogy azonosítják kulcs- 
elemeiket és a felületen áthaladó adatokat. Egy tervezési minta azt is megmondhatja, hogy 
mit e tegyünk a felületbe. Az Emlékeztető minta jó példa erre. Leírja, hogyan zárjuk egy- 
ségbe és mentsük egy objektum belső állapotát, hogy azt majd később visszaállíthassuk eb- 
be az állapotába. A minta előírja, hogy az emlékeztető objektumoknak két felületet kell 
meghatározniuk: egy korlátozottat, amivel az ügyfelek tárolhatnak és másolhatnak emlé- 
keztetőket, és egy kitüntetettet, amit csak az eredeti objektum használhat az állapot elraktá- 
rozására és visszaállítására. 


A tervezési minták a felületek közötti kapcsolatokat is meghatározzák. Sokszor elvárják, 
hogy egyes osztályoknak hasonló legyen a felülete, vagy megszorításokat adnak az osztá- 
lyok felületére. Például mind a Díszítő, mind a Helyettes minta elvárja a Díszítő és Helyettes 
objektumok felületétől, hogy megegyezzenek a díszített, illetve helyettesített objektumok 
felületével. A Látogató mintában a Látogató felületének minden objektumosztályt mutatnia 
kell, amit a látogatók látogathatnak. 


Az objektummegvalósítások meghatározása 

Eddig keveset mondtunk arról, hogy ténylegesen hogyan is határozunk meg egy objektumot. 
Nos, az objektum megvalósítását az osztálya határozza meg. Az osztály adja meg az objektum 
belső adatait és ábrázolását, illetve a műveleteket, amelyeket az objektum végre tud hajtani. 


OMT alapú jelölésünk (amit a B függelékben foglaltunk össze) az osztályokat téglalappal 
ábrázolja, félkövérrel szedett névvel. A műveletek normál betűkkel szedve, az osztály neve 
alatt találhatók. Bármely adat, amit az osztály határoz meg, a műveletek után következik. 
Vonalak választják el az osztály nevét a műveletektől, és a műveleteket az adatoktól: 





OsztályNév 





Művelet1() 
Típus Művelet2() 
keeseesásmsözzüzttezattetanáseű 


példányVáltozó1 
Típus példányVáltozó2 
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A visszatérési típusok és változópéldány-típusok elhagyhatók, mivel nem tételezünk fel sta- 
tikusan típusos megvalósítási nyelvet. 


Az objektumok egy osztály példányosításával jönnek létre. Az objektum az osztály egy példánya. 
Az osztály példányosításának folyamata során az osztály tárhelyet juttat az objektum belső 
adatainak (amelyek változópéldányokból épülnek fel) és hozzárendeli a műveleteket ezekhez az 
adatokhoz. Az osztály példányosításával sok hasonló objektumpéldány jöhet létre. 


Az alábbi ábrán a szaggatott, nyílhegyű vonal egy olyan osztályt jelöl, ami egy másik osz- 
tály objektumát példányosítja. A nyíl a példányosított objektumok osztályára mutat. 











példányosító t ESSZÉ ÁS LEE kel példányosított 





A már létező osztályokból az osztályöröklés segítségével hozhatunk létre új osztályokat, 
Ha egy alosztály örököl egy szülőosztálytól, akkor a szülő által leírt minden adatot és művele- 
tet meghatároz. Az alosztály objektumainak példányai minden, az alosztály és a szülőosztá- 
lyok által meghatározott adatot tartalmaznak, és minden műveletet végre tudnak majd haj- 
tani, amit az alosztály és a szülőosztályai tudnak. Az alosztály kapcsolatot függőleges vonal- 
lal és egy háromszöggel ábrázoljuk: 





SzülőOsztály 
Művelet() 




















Alosztály 





Az elvont osztály (absztrakt osztály) lényege, hogy általános felületet ír le az alosztályai szá- 
mára. Az elvont osztály megvalósítása egy részét vagy egészét olyan műveletekre ruházza át, 
amelyeket alosztályai határoznak majd meg, vagyis az elvont osztályból nem készíthetünk 
példányt. Azokat a műveleteket, amelyeket egy elvont osztály bevezet, de meg nem valósít, 
elvont műveleteknek hívjuk. Azon osztályok neve, amelyek nem elvontak, konkrét osztály. 


Az alosztályok finomíthatják vagy felülbírálhatják szülőosztályuk viselkedését. Konkrétab- 
ban, egy osztály felülírhat egy műveletet, amit a szülőosztálya határozott meg. A felülírás (fe- 
lülbírálás) megadja az esélyt az alosztályoknak, hogy maguk kezeljék a kérelmeket a szülő- 
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osztályaik helyett. Az öröklés lehetővé teszi az osztályok más osztályok egyszerű kibővíté- 
sével való meghatározását, így könnyen alkothatunk objektumcsaládokat, amelyeknek ro- 
kon feladatuk van. 


Az elvont osztályok nevét dőlt betűvel szedtük, hogy megkülönböztethetőek legyenek 
a konkrét osztályoktól. Dőlt betű jelzi az elvont műveleteket is. Néha az ábrán egy művelet 
megvalósításaként álkód (pszeudokód) tűnik fel, ilyenkor a kód egy szamárfüles dobozban 
lesz, amit szaggatott vonal köt össze az őt megvalósító művelettel. 





ElvontoOsztály 
Műveletf) 








KonkrétAlosztály 
Művelet) zo NSEEÉS VENENSZSÉT S ORE TSESA TE TeRE TSZEEB megvalósítási álkód 











A. mixin ( bekeveredő", ,bekevert" osztály) olyan osztály, ami másik választható felületet 
vagy szolgáltatást nyújt más osztályoknak. Az elvont osztályhoz hasonlóan ezt sem lehet 
példányosítani. A mixin osztályokhoz többszörös öröklés szükséges: 








LétezőOsztály Mixin 
LétezőMűvelet() MixinMűvelet() 


A A 


BővítettOsztály 


LétezőMűvelet() 
MixinMűvelet() 
































Osztály- és felületöröklés 


Fontos, hogy megértsük a különbséget az objektum osztálya és típusa között. Az osztály az 
adott objektum megvalósításának módját, vagyis az objektum belső állapotát és műveletei- 
nek megvalósítását határozza meg. Ezzel szemben az objektum típusa csak a felületére utal, 
vagyis azoknak a kérelmeknek a halmazára, amire válaszolni tud. Egy objektumnak több tí- 
pusa lehet, és különböző osztályú objektumok is tartozhatnak egy típusba. 
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Természetesen közeli rokonság van az osztály és a típus között. Mivel az osztály meghatá- 
rozza az objektum által végrehajtható műveleteket, az objektum típusát is meghatározza. 
Ha azt mondjuk, hogy egy objektum egy osztály példánya, beleértjük azt is, hogy az objek- 
tum támogatja az osztály által értelmezett felületet. 


Az olyan nyelvek, mint a C-t vagy az Eiffel, osztályokkal határozzák meg az objektum tí- 
pusát és megvalósítását is. A Smalltalk programok nem adják meg a változók típusát; vagyis 
a fordító nem ellenőrzi, hogy egy adott változóhoz rendelt objektumok típusai altípusai-e 
a változó típusának. Üzenet küldéséhez meg kell néznünk, hogy a fogadó osztályának 
megvalósítása támogatja-e az üzenetet, de nem kell megnéznünk, hogy a fogadó példánya- 
e egy bizonyos osztálynak. 


Fontos megérteni továbbá az osztályöröklés és a felületöröklés (vagy altípus-létrehozás) 
közötti különbséget is. Az osztályöröklés egy objektum megvalósítását egy másik objektum 
megvalósításának segítségével adja meg. Röviden, ez egy olyan módszer, amivel kód és áb- 
rázolás osztható meg. Ezzel szemben a felületöröklés azt írja le, hogy egy objektumot mikor 
használhatunk egy másik helyett, 


Könnyű összekeverni ezt a két fogalmat, mivel sok nyelv nem tesz egyértelmű különbsé- 
get. Az olyan nyelvekben, mint a C---- és az Eiffel, az öröklődés egyszerre jelenti a felület és 
a megvalósítás öröklését. Az általános felületöröklési mód a C--t-ban az, ha nyilvánosan 
olyan osztálytól öröklünk, amelynek (tisztán) virtuális tagfüggvényei vannak. A tiszta felü- 
letöröklést úgy közelíthetjük meg e nyelvben, hogy nyilvánosan öröklünk tisztán elvont 
osztályokból. A tiszta megvalósítás- vagy osztályöröklés privát örökléssel közelíthető. 
A Smalltalkban az öröklés csak megvalósítás-öröklést jelent. Bármely osztály példányát 
hozzá lehet rendelni egy változóhoz, amíg a példány támogatja a változó értékén végzett 
műveletet. 


Bár a legtöbb programozási nyelv nem tesz különbséget a felület- és megvalósítás-öröklés 
között, a gyakorlatban mégis van megkülönböztetés. A Smalltalk programozók általában 
úgy tesznek, mintha az alosztályok altípusok lennének (bár van pár jól ismert kivétel 
[Coo92]; a Cs programozók pedig elvont osztályokban meghatározott típusokon keresz- 
tül kezelik az objektumokat. 





Sok tervezési minta függ ettől a különbségtől. Például a Felelősséglánc minta objektumai- 
nak közös típusuk kell, hogy legyen, de megvalósításuk általában különböző. Az Összeté- 
tel mintában az Elem (ComponenO közös felületet határoz meg, de az Összetétel 
(Composite) gyakran közös megvalósítást. A Parancs, a Megfigyelő, az Állapot és a Straté- 
gia mintákat sokszor elvont osztályokkal valósítják meg, amelyek tisztán felületek. 
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Megvalósítás helyett felületre programozás 


Az osztályöröklés alapjában véve csak egy módszer, amivel az alkalmazás szolgáltatásait 
a szülő szolgáltatásaival bővítjük ki. Segítségével gyorsan hozhatunk létre új objektumokat 
egy régi alapján. Különösebb munka nélkül kaphatunk új megvalósításokat, egyszerűen örö- 
kölve a létező osztályokból, amire szükségünk van. 


Mindazonáltal a megvalósítás újrahasznosítása még nem minden. Az öröklés azon tulajdon- 
sága, hogy egyező felületű objektumok családját képes meghatározni (általában egy elvont 
osztályból örökölve) szintén fontos. Miért? Mert ezen alapul a többalakúság. 





Ha figyelmesen használjuk az öröklést (egyesek szerint szabályosan), akkor minden, adott 
elvont osztályból származó osztály osztozik majd a szülő felületén. Ebből az következik, 
hogy egy alosztály a műveletekhez csak adhat, vagy felülírhatja azokat, de szülőosztályá- 
nak műveleteit nem tudja elrejteni. Így minden alosztály tud majd válaszolni az elvont osz- 
tály felületében szereplő kérelmekre, amik így az elvont osztály altípusává válnak. 


Két előny is származik abból, ha az objektumokat kizárólag az elvont osztályban meghatá- 
rozott felület szintjén kezeljük: 


1. Az ügyfelek egészen addig nem veszik figyelembe a felhasznált objektumok típusát, 
amíg az objektumok felülete az ügyfelek által vártnak megfelel. 

2. Az ügyfelek nem veszik figyelembe az ezeket az objektumokat megvalósító osztá- 
lyokat. Csak a felületet meghatározó elvont osztály(oka)t ismerik. 


Ez annyira lecsökkenti az alrendszerek közötti megvalósítás-függőséget, hogy az az újra- 
hasznosítható objektumközpontú terv első alapelvéhez vezet: 


Programozzunk a felületre a megvalósítás helyett. 


Ne konkrét osztályok példányaiként vezessük be változóinkat, csak az elvont osztályban 
meghatározott felületet bővítsük. Ahogy látni fogjuk, ez a könyvben lévő tervezési minták 
egyik közös elve. 


Persze valahol a rendszerünkben példányosítanunk kell majd konkrét osztályokat (vagyis 
meg kell adnunk a tényleges megvalósítást), és a létrehozási minták (Elvont gyár, Építő, Gyár- 
tófüggvény, Prototípus és Egyke) éppen ezt teszik lehetővé. Az objektum-létrehozás folyama- 
tának elvonatkoztatásával ezek a minták különböző módokat nyújtanak arra, hogy egy felüle- 
tet a megvalósításával anélkül kapcsolhassuk össze a példányosításnál, hogy a megvalósítás 
módjáról tudomásunk lenne. A létrehozási minták biztosítják, hogy a rendszerünk felület-, és 
ne megvalósítás-központú legyen. 
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Az újrahasznosítási szerkezetek használata 


A legtöbben megértik az objektumok, felületek, osztályok és az öröklés fogalmát. A kihívás 
igazán abban rejlik, hogy alkalmazásukkal rugalmas, újrahasznosítható programokat épít- 
sünk, és a tervezési minták megmutatják, hogy ezt hogyan is kell. 


Öröklés vagy összetétel? 

Az objektumközpontú rendszerekben a képességek újrahasznosításának két leggyakrabban 
használt módszere az osztályöröklés és az objektum-összetétel (objektumkompozíció). Ahogy 
azt már említettük, az osztályöröklés arra ad módot, hogy egy osztály megvalósítását egy 
másik osztály segítségével határozzuk meg. Az alosztályokon keresztül történő újrahasznosí- 
tást fehér dobozos újrahasznosításnak nevezzük. A , fehér doboz? a láthatóságra utal: az öröklés- 
sel az alosztályok gyakran látják a szülő osztály belső részeit. 


Az objektum-összetétel az osztályöröklés alternatívája. Itt az új szolgáltatások úgy jönnek 
létre, hogy kisebb részekből építünk fel objektumokat, hogy több szolgáltatással rendel- 
kezzenek. Az objektum-összetételnél az összeépített objektumoknak jól meghatározott fe- 
lülettel kell rendelkezniük. Az ilyen újrahasznosítást fekete dobozos újrahasznosításnak nevez- 
zük, mert az objektumok belső részei láthatatlanok. Az objektumok , fekete dobozokként" 
jelennek meg. 


Az öröklésnek és az összetételnek egyaránt megvannak a maga előnyei és hátrányai. 
Az öröklődés statikusan, fordításkor történik, és használata egyértelmű, mivel közvetlenül 
a programnyelv támogatja; továbbá az osztályöröklés könnyebbé teszi az újrahasznosított 
megvalósítás módosítását is. Ha egy alosztály felülírja a műveletek némelyikét, de nem 
mindet, akkor a leszármazottak műveleteit is megváltoztathatja, feltételezve, hogy azok 
a felülírt műveleteket hívják. 


De az osztályöröklésnek vannak hátrányai is. Először is, a szülőosztályoktól örökölt megva- 
lósításokat futásidőben nem változtathatjuk meg, mivel az öröklés már fordításkor eldől, 
Másodszor - és ez sokkal rosszabb -, a szülőosztályok gyakran alosztályaik fizikai megjele- 
nését is meghatározzák, legalább részben. Mivel az öröklés megengedi, hogy egy alosztály 
betekintést nyerjen szülője megvalósításába, gyakran mondják, hogy ,az öröklés megszegi 
az egységbe zárás szabályát" ISny86]. Az alosztály megvalósítása annyira kötődik a szülő- 
osztály megvalósításához, hogy a szülő megvalósításában a legkisebb változtatás is az al- 
osztály változását vonja maga után. 


A megvalósítási függőségek gondot okozhatnak az alosztályok újrahasznosításánál. Ha az 
örökölt megvalósítás bármely szempontból nem felel meg az új feladatnak, arra kényszerü- 
lünk, hogy újraírjuk vagy valami megfelelőbbel helyettesítsük a szülőosztályt. Ez a függő- 
ség korlátozza a rugalmasságot, és végül az újrahasznosíthatóságot. Ezt úgy orvosolhatjuk, 
ha csak elvont osztályoktól öröklünk, mivel azok általában semennyi vagy csak kevés meg- 
valósításra vonatkozó részt tartalmaznak. 
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Az objektum-összetétel dinamikusan, futásidőben történik, olyan objektumokon keresztül, 
amelyek hivatkozásokat szereznek más objektumokra. Az összetételhez szükséges, hogy az 
objektumok figyelembe vegyék egymás felületét, amihez figyelmesen megtervezett felüle- 
tek kellenek, amelyek lehetővé teszik, hogy az objektumokat sok másikkal együtt használ- 
juk. A módszer előnye viszont, hogy mivel az objektumokat csak a felületükön keresztül ér- 
hetjük el, nem szegjük meg az egységbe zárás elvét. Bármely objektumot lecserélhetünk egy 
másikra futásidőben, amíg a típusaik egyeznek. Továbbá, mivel az objektumok megvalósítá- 
sa objektumfelületek segítségével épül fel, sokkal kevesebb lesz a megvalósítási függőség. 


Az objektum-összetételnek még egy hatása van a rendszer szerkezetére: az osztályöröklés- 
sel szemben segít az osztályok egységbe zárásában és abban, hogy azok egy feladatra össz- 
pontosíthassanak. Az osztályok és osztályhierarchiák kicsik maradnak, és kevésbé valószí- 
nű, hogy kezelhetetlen szörnyekké duzzadnak. Másrészről az objektum-összetételen ala- 
puló tervezésben több objektumunk lesz (ha osztályunk kevesebb is), és a rendszer visel- 
kedése ezek kapcsolataitól függ majd, nem pedig egyetlen osztály határozza meg. 


Ez vezet el minket az objektumközpontú tervezés második alapelvéhez: 
Használjunk objektum-összetételt osztályöröklés helyett, amikor csak lehet. 


A legjobb az lenne, ha nem kellene új elemeket létrehoznunk, hogy valamit újra felhasznál- 
hassunk, és minden szükséges képességre szert tehetnénk, ha összepárosítanánk a létező 
objektumokat. De ez ritkán történik meg, mivel a rendelkezésünkre álló elemek tárháza 
a gyakorlatban soha nem elég gazdag. Az öröklésből eredő újrahasznosíthatóság viszont 
könnyebbé teszi új elemek építését a régiekből: az öröklés és az összetétel tehát együtt 
használatosak. 


A gyakorlat azonban azt mutatja, hogy a tervezők túlzott előszeretettel használják az örök- 
lést, mint újrahasznosítási módszert, és a tervek sokszor újrahasznosíthatóbbá (és egysze- 
rűbbé) válnának, ha gyakrabban fordulnánk az objektum-összetételhez. A bemutatott ter- 
vezési mintákban, mint majd láthatjuk, az objektum-összetétel újra és újra felbukkan. 


Képviselet 

A képviselet (delegáció) az összetétel olyan erejű újrahasznosítási módszerré tétele, mint az 
öröklés ILie86, JZ91]. A kérelmek kezelésében ekkor két objektum vesz részt: egy fogadó 
objektum, és a képviselője (delegáltja), amelyre a fogadó műveleteket ruház át. Ez az alosz- 
tályok szülőknek címzett kérelem-átirányításához hasonló. De az öröklésnél az örökölt mű- 
veletek mindig utalhatnak a fogadó objektumra, amit a Ct-t-ban a this, a Smalltalkban 
a sel£ változó valósít meg. Hogy ugyanezt a hatást érjük el a képviselettel, a fogadó , átad- 
ja magát" a képviselőnek, hogy az átruházott művelet a fogadóra utalhasson. 


22 


Programtervezési minták 





Például ahelyett, hogy az Ablak alosztálya lenne a Téglalapnak (mivel az ablakok téglalap 
alakúak), az Ablak osztály felhasználhatná a Téglalap viselkedését azzal, hogy egy saját 
Téglalap példányváltozóra Téglalap-szerű viselkedést ruház. Más szavakkal, ahelyett, hogy 
egy Ablak Téglalap lenne, egyszerűen lenne egy Téglalapja. Az Ablaknak mostantól kifeje- 
Zetten továbbítania kell a kérelmeket a Téglalap-példányának, pedig eddig örökölte volna 
ezeket a műveleteket. 


A következő ábra azt mutatja, ahogyan az Ablak osztály átadja a Terület műveletét a Tégla- 
lap-példánynak. 


Ablak ; 
téglalap 

Terület) 
j 
1 
1 
1 
1 
; 
T 
! 

return téglalap—- Terület) return szélesség " magasság 


Az egyszerű nyílban végződő vonal azt mutatja, hogy egy osztály egy másik osztály egy 
példányára hivatkozik. A hivatkozásnak külön neve is lehet, ebben az esetben , teglalap". 
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A képviselet legfőbb előnye az, hogy segítségével könnyen alakíthatunk ki viselkedéseket 
futásidőben, és megváltoztathatjuk összetételük módját. Ablakunk kör alakúvá válhat futás- 
időben, egyszerűen kicserélve a Téglalap-példányt egy Kör-példányra, amennyiben a Tég- 
lalap és a Kör azonos típusúak. 


A képviseletnek ugyanaz a hátránya, mint általában a többi objektum-összetételi rugalmas- 
ságnövelő eljárásnak: a dinamikus, erősen paraméterezett programokat nehezebb megérte- 
ni, mint a statikusabbakat. Vannak ugyan futásidejű hátrányai is, de az emberi tényezőt 
érintő hátrányok hosszú távon sokkal fontosabbak. A képviselet csak akkor jó választás, ha 
többet egyszerűsít, mint bonyolít. Nem könnyű szabályokat adni rá, hogy mikor érdemes 
használni, mivel hatékonysága azon múlik, milyen környezetben használjuk, és mennyi ta- 
pasztalatunk van a használatában. A képviselet legjobban erősen stilizált formában használ- 
ható — vagyis a szabványos mintákban. 


Több tervezési minta használja a képviseletet. Az Állapot, a Stratégia és a Látogató minták 
erősen függnek tőle. Az Állapot mintában az objektumok egy Állapot objektumnak adnak 
át kérelmeket, ami az adott objektum aktuális állapotát tükrözi. A Stratégia mintában az ob- 


1. fejezet " Bevezetés 





23 





jektumok adott kérelmet ruháznak át egy objektumra, ami a kérelem teljesítésének módját 
képviseli. Egy objektumnak csak egy állapota, de több módszere (stratégiája) is lehet a kü- 
lönböző kérelmekhez. Mindkét minta célja, hogy megváltoztassa egy objektum viselkedé- 
sét azzal, hogy megváltoztatja az objektumokat, amelyeknek a kérelmeket átadja. A Látoga- 
tó mintában az egy adott objektumszerkezet minden elemén végrehajtott műveletet mindig 
a Látogató objektum veszi át. 

Más minták kevésbé használják a képviseletet. A Közvetítő minta egy objektumot vezet be, 
ami közvetít más objektumok között. Néha a közvetítő objektum úgy valósítja meg a műve- 
leteket, hogy egyszerűen továbbítja azokat más objektumoknak; máskor hivatkozást is küld 
magára, vagyis valódi képviseletet használ. A Felelősséglánc minta úgy kezeli a kérelmeket, 
hogy objektumok láncán keresztül továbbítja azokat egyik objektumtól a másikig. Néha ez 
a kérelem magával viszi az eredeti fogadó objektumra való hivatkozást, és ilyenkor a minta 
képviseletet használ. A Híd minta szétválasztja az elvont fogalmat a megvalósításától. 
Ha a fogalom és egy adott megvalósítása szorosan összekapcsolódnak, az elvont ábrázolás 
egyszerűen ruházhat át műveleteket az adott megvalósításra. 


A képviselet szélsőséges példa az objektum-összetételre, ami azt mutatja, hogy az öröklés, 
mint kód-újrahasznosítási megoldás, mindig helyettesíthető objektum-összetétellel. 


Öröklés és paraméterezett típusok 

Egy másik (nem szigorúan objektumközpontú) eljárás a szolgáltatások újrahasznosítására 
a paraméterezett típusok használata, amiket generikus vagy általános programozási alegységeknek 
(Ada, Eiffel), illetve sablonoknak (template, C----) hívunk. Ez a módszer egy típus meghatározá- 
sát teszi lehetővé anélkül, hogy minden általa felhasznált típust megadnánk. A meghatározat- 
lan típusokat paraméterekként látjuk a használat helyén. Például egy Lista osztályt elemeinek 
típusával paraméterezhetünk. Ahhoz, hogy egészek egy listáját vezessük be, az ,integer" tí- 
pust adjuk át paraméterként a paraméterezett típusú Listának. Ha egy karakterlánc objektu- 
mokbáól álló listát szeretnénk megadni, a , String" típust adjuk át paraméterként, A nyelvi meg- 
valósítás a Lista osztálysablon testreszabott változatát készíti el minden elemtípushoz. 


A paraméterezett típusokkal egy harmadik módszert kaptunk (az osztályöröklés és az ob- 
jektum-összetétel mellé), amellyel objektumközpontú rendszerek viselkedését építhetjük 
fel. Sokféle tervet megvalósíthatunk e három módszer használatával. Ha egy rendező eljá- 
rásnak paraméterként meg szeretnénk adni, hogy milyen műveletet használjon az elemek 
összehasonlítására, ezt a következő eszközökkel valósíthatjuk meg: 


1. alosztályokkal megvalósított művelet (Sablonfüggvény felhasználása), 

2. egy objektum kötelezettsége, amit a rendező eljárásnak átadunk (Stratégia), vagy 

3. egy Ctt sablon vagy Ada általános programozási alegység argumentuma, ami meg- 
határozza az elemek összehasonlítására szolgáló függvény nevét. 
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A fenti módszerek között lényeges különbségek vannak. Az objektum-összetétel segítségé- 
vel megváltoztathatjuk a futásidőben létrejövő viselkedést, de közvetettségre van szükség, 
ami néha kevésbé hatékony. Az öröklés segítségével alapértelmezett megvalósítással lát- 
hatjuk el a műveleteket, amit majd az alosztályok felülírhatnak. A paraméterezett típusok 
segítségével megváltoztathatók az osztályok által használt típusok. De sem az öröklés, sem 
a paraméterezett típus nem változhat futásidőben. Hogy melyik megközelítés a legjobb, az 
a terven és a megvalósítás megszorításain múlik. 


Az e könyvben leírt minták egyike sem foglalkozik a paraméterezett típusokkal, bár eseten- 
ként használjuk minták C--4 megvalósításának testreszabására. A paraméterezett típusokra 
semmi szükség az olyan nyelvekben, mint a Smalltalk, amelyekben nincs fordítási idejű tí- 
pusellenőrzés. 








Futás- és fordítási idejű szerkezetek összehasonlítása 

Egy objektumközpontú program futásidejű szerkezete gyakran kevés hasonlatosságot mutat 
a kód szerkezetével. Fordításkor a kód szerkezete statikus; meghatározott öröklési kapcsolat- 
ban álló osztályokból áll. A program futásidejű szerkezete egymással társalgó objektumok 
gyorsan változó hálózatából áll. Valójában a két szerkezet egymástól nagyban fi üggetlen. Ha az 
egyikből szeretnénk megérteni a másikat, az olyan, mintha az élővilág dinamikáját szeretnénk 
megérteni pusztán az állatok és növények rendszertani leírásából, és fordítva. 





Vessünk egy pillantást az objektumok összesítése (aggregáció) és ismeretsége (acguaintance) 
közötti különbségre, és hogy mennyire máshogyan nyilvánulnak meg fordítási és futásidőben. 
Az összesítés azt sugallja, hogy az egyik objektum a másik tulajdonában van vagy felelős érte. 
Általában úgy mondjuk, hogy egy objektum egy másiknak julajdonosa vagy része. Az Összesí- 
tés arra utal, hogy az összesített objektumnak és tulajdonosának egyforma az életideje, 





Az ismeretség arra utal, hogy egy objektum egyszerűen tud egy másikról. Néha az ismeretsé- 
get ,asszociációnak" vagy , használó" kapcsolatnak (using) is hívják. Az ismerős objektumok 
kérhetnek műveleteket egymástól, de nem felelősek egymásért. Az ismeretség gyengébb 
kapcsolat az összesítésnél, és sokkal lazább összefüggést feltételez az objektumok között. 


Ábráinkban a sima nyílhegyű vonal ismeretséget jelent. Az a nyíl viszont, amelynek végén 
rombusz található, összesítést jelöl: 














Összesítő teggéssésíletírűldny se Összesített 
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Az összesítést és az ismeretséget könnyű összekeverni, mivel gyakran ugyanúgy valósítjuk 
meg őket. A Smalltalkban minden változó hivatkozás más objektumokra, a programozási 
nyelv nem tesz különbséget összesítés és ismeretség között. A C44-ban az összesítés meg- 
valósítása tagváltozó-példányokkal történik, de gyakrabban történik a megvalósítás olyan 
mutatókkal és hivatkozásokkal, amelyek példányokra mutatnak. Az ismeretséget is muta- 
tókkal és hivatkozásokkal valósítjuk meg. 





Végső soron az ismeretséget és az összesítést inkább a cél határozza meg, nem kifejezett 
nyelvi eszközök. Talán nehéz felismerni a különbséget a fordítási idejű szerkezetben, de 
mégis fontos. Összesítő kapcsolatból általában kevesebb van, de azok tartósabbak az isme- 
retségeknél. Az ismeretségek ezzel szemben sokkal gyakrabban létesülnek újra és újra, né- 
ha csak egy művelet erejéig létezve. Az ismeretségek dinamikusabbak is, így nehezebb 
azokat megtalálni a forráskódban. 


Ilyen különbségekkel a program futásidejű és fordítási idejű szerkezetében világos, hogy 
a kód nem fogja felfedni a rendszer teljes működését. A rendszer futásidejű szerkezetét in- 
kább a tervező, mint a nyelv adja meg. Az objektumok és típusaik közti kapcsolatokat nagy 
gonddal kell megterveznünk, mert ezek határozzák meg, mennyire jó vagy rossz a futáside- 
jű szerkezet. 


Sok tervezési mintában (főleg amelyek objektumszinten működnek) látható a fordítási és fu- 
tásidejű szerkezetek közti különbség. A Összetétel és a Díszítő minták különösen hasznosak 
a bonyolult futásidejű szerkezetek építésében. A Megfigyelő olyan futásidejű szerkezeteket tar- 
talmaz, amelyeket gyakran nehéz megérteni a minta ismerete nélkül. A Felelősséglánc szintén 
olyan kommunikációs mintákat eredményez, amiket az öröklés nem mutat be. A futásidejű 
szerkezetek általában nem látszanak tisztán a kódból, amíg meg nem értjük a mintákat. 


Változásra tervezve 

Az újrahasznosíthatóság kulcsa az új igények és a létező igények változásának megérzésé- 
ben rejlik, és abban, hogy úgy tervezzük meg rendszerünket, hogy az ennek megfelelően 
fejlődhessen. 


Ahhoz, hogy olyan rendszert tervezzünk, ami a változásoknak is megfelel, figyelembe kell 
vennünk, hogy a rendszer milyen változásokon kell majd, hogy átessen életében. Az olyan 
terv, ami nem veszi figyelembe a változásokat, az alapos újratervezés későbbi szükségessé- 
gének kockázatát rejti. A változások között előfordulhat osztályok új meghatározása és új 
megvalósítása, az ügyfél változása, és újratesztelés. Az újratervezés a programrendszer szá- 
mos részét érinti, és a váratlan változások kivétel nélkül költségesek. 


A tervezési minták segítségével ez elkerülhető, segítségükkel biztosíthatjuk, hogy a rendszer 
meghatározott módokon módosítható legyen. Minden tervezési mintában vannak a rend- 
szerszerkezetnek olyan részei, amelyek a többitől függetlenül változtathatók, ezzel téve el- 
lenállóbbá a rendszert egyes változásfajtákkal szemben. 
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Az alábbaikban leírtuk az újratervezés néhány gyakori okát, valamint azt, hogy az egyes 
tervezési minták milyen megoldást adnak ezekre a problémákra: 


1 


Objektum létrehozása kifejezett osztálymegadással. Ha egy objektum létrehozásánál 
megadjuk az osztály nevét, az egyetlen megvalósításra korlátoz, és nem egyfajta fe- 
lületre. Ez a korlátozás bonyolíthatja a későbbi változtatásokat. Elkerüléséhez köz- 
vetve hozzuk létre az objektumokat. 

Tervezési minták: Elvont gyár, Gyártófüggvény, Prototípus. 

Konkrét műveletekre támaszkodás. Ha konkrét műveleteket adunk meg, a kérelem 
egyfajta kielégítési módjára szorítkozunk. A megváltoztathatatlanul kódolt kérelmek 
mellőzésével könnyebbé válik a kérelem kielégítésének megváltoztatása mind fordí- 
táskor, mind futásidőben. 

Tervezési minták: Felelősséglánc, Parancs. 

Függőség a harduer- és programkörnyezettől. A külső, operációs rendszeri és alkal- 
mazás-programozási felületek (API-k) különböznek a különböző hardver- és prog- 
ramkörnyezetekben. A környezetfüggő programot nehezebb más környezetekhez 
illeszteni. Még az is lehet, hogy nehézzé válik a programot naprakészen tartani az 
eredeti környezetében. Ezért fontos, hogy rendszerünk minél környezetfüggetleneb- 
bé váljon. 

Tervezési minták: Elvont gyár, Híd. 





tudják, hogy az objektumot hogyan ábrázoljuk, tároljuk, helyezzük el, vagy valósít- 
juk meg, lehet, hogy változásokra szorulnak, ha maga az objektum is változik. Ha 
ezeket az információkat elrejtjük az ügyfelek elől, nem kell annyit változtatnunk. 
Tervezési minták: Elvont gyár, Híd, Emlékeztető, Helyettes. 

Algoritmikus függőségek. Az algoritmusok hatékonyságát gyakran utólag finomhan- 
golják, kibővítik őket, vagy lecserélik a fejlesztés és újrahasznosítás során. Azok az 
objektumok, amelyek egy ilyen algoritmustól függnek, kénytelenek lesznek megvál- 
tozni, ezért azokat az algoritmusokat, amelyek valószínűleg meg fognak változni, el 
kell különíteni. 

Tervezési minták: Építő, Bejáró, Stratégia, Sablonfüggvény, Látogató. 

Szoros csatolás. A szorosan összekapcsolt osztályokat nehéz elkülönítve felhasznál- 
ni, mivel függnek egymástól. A szoros csatolás oszthatatlan rendszerekhez vezet, 
ahol nem változtathatunk vagy törölhetünk egy osztályt a rendszerből számos más 
osztály megértése és átírása nélkül. A rendszer nehezen átlátható, más rendszerre 
nehezen átvihető és alig kezelhető masszává válik. 

A laza csatolás növeli annak esélyét, hogy egy osztály önmagában is felhasználható 
lesz, és hogy a rendszert könnyebb lesz megtanulni, más rendszerre átvinni, módosí- 
tani és kibővíteni. A tervezési minták olyan eljárásokkal segítik a laza csatolású rend- 
szereket, mint az elvont csatolás és a rétegezés. 

Tervezési minták: Elvont gyár, Híd, Felelősséglánc, Parancs, Homlokzat, Közvetítő, 
Megfigyelő. 
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7. A működés kibővítése alosztályokkal. Egy objektum testreszabása alosztályokkal 
nem mindig könnyű feladat. Minden új osztálynak egy rögzített megvalósításhoz kell 
igazodnia (előkészítéskor, lezáráskor stb.). Egy alosztály meghatározásához a szülő 
mélyreható megértése szükséges. Például egy művelet felülírása talán egy másik fe- 

ülírását is maga után vonhatja, vagy lehet, hogy egy felülírt művelet szükséges egy 

örökölt művelet hívásához. Továbbá az alosztályok létrehozása az osztályok számá- 
nak robbanásszerű növekedéséhez is vezethet, mivel már egy egyszerű bővítés is le- 
het, hogy több új alosztály bevezetését követeli meg. 

Az objektum-összetétel általában, a képviselet teljes egészében rugalmas alternatívá- 

kat kínálnak az öröklés helyett a viselkedések kialakítására. Egy alkalmazáshoz már 

étező objektumok összeépítésével, új alosz 








ályok meghatározása nélkül adhatunk 
új szolgáltatásokat. Másrészről az objektum-összetétel túlzott használata megnehezít- 
leti a szerkezet megértését, Több tervezési minta olyan terveket eredményez, ame- 
yekben testhez álló szolgáltatásokat hozhatunk létre csupán egy alosztály meghatá- 
rozásával, míg a példányokat létező osztályok összetételével állítjuk elő. 
Tervezési minták: Híd, Felelősséglánc, Összetétel, Díszítő, Megfigyelő, Stratégia. 

8. Osztályok kényelmetlen módosítása. Van, amikor olyan osztályt kell megváltoztat- 
nunk, amit kényelmesen lehetetlen. Talán a forráskódra lenne szükség, de nem áll 
rendelkezésünkre (például egy megvásárolható osztálykönyvtárnál), vagy bármilyen 
változás rengeteg alosztály megváltoztatását vonná maga után. A tervezési minták 
ezekre az esetekre is adnak útmutatást. 

Tervezési minták: Illesztő, Díszítő, Látogató. 

















Ezen példák jól mutatják, hogy a tervezési minták hogyan segíthetnek a program rugalma- 
sabbá tételében. Azt, hogy ez a rugalmasság mennyire fontos, az építendő program jellege 
dönti el. Lássuk, hogyan működnek a tervezési minták három elég tág programcsoportban: 
az alkalmazásokban, az elemkészletekben és a keretrendszerekben. 


Alkalmazások 
Ha olyan alkalmazást írunk, mint például egy szövegszerkesztő vagy egy táblázatkezelő, akkor 
a belső újrahasznosíthatóság, a karbantarthatóság és a fejleszthetőség nagyon fontosak. A belső 
újrahasznosíthatóság biztosítja, hogy ne kelljen annál többet tervezni és megvalósítani, mint 
amit muszáj. Azok a tervezési minták, amelyek csökkentik a függőségeket, növelik a belső új. 
rahasznosíthatóságot. A laza csatolás megnöveli annak esélyét, hogy egy objektum osztálya 
együtt tud működni több másikkal. Például amikor kizárjuk az adott műveletektől való függő- 
ségeket azzal, hogy minden műveletet elkülönítünk és egységbe zárunk, könnyebbé tesszük 
egy művelet különböző környezetekben történő felhasználását. Ugyanez történhet, ha eltávo 
lítjuk az algoritmikus és ábrázolási függőségeket. 


A tervezési minták továbbá könnyebben karbantarthatóbbá tesznek egy alkalmazást azzal 
hogy csökkentik a környezeti függőségeket, és rétegezik a rendszert. Javítják a fejleszthetősé. 
get azzal, hogy megmutatják, hogyan kell az osztályhierarchiákat kibővíteni, és hogyan kell 
az objektum-összetételt kihasználni. A fejleszthetőséget a laza csatolás is segíti. Egy elkülöní- 
tett osztály fejlesztése könnyebb, mert nem kell sok függőséget figyelembe venni. 


1 
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Elemkészletek 


Az alkalmazások gyakran előre elkészített könyvtárakból használnak egy vagy akár több osz- 
tályt is. Ezeket az előre létrehozott osztályokat hívjuk elemkészleteknek (eszközkészlet, toolki0. 
Az elemkészlet kapcsolódó és újrahasznosítható osztályokból áll, amelyek hasznos, általános 
célú szolgáltatásokat nyújtanak. Egy példa az elemkészletre a gyűjteményosztályok készlete, 
amely a listák, asszociatív táblák, vermek és hasonlók osztályait tartalmazza. A C-t [/O 
(kimeneti-bemeneti) könyvtára is jó példa. Az elemkészletek nem erőszakolnak egy meghatá- 
rozott tervet az alkalmazásra, csak olyan képességekkel látják el, amelyek megkönnyítik 
a munkáját, a mi számunkra pedig lehetővé teszik a megvalósítást az általános szolgáltatások 
újrakódolása nélkül. Az elemkészletek nagy hangsúlyt fektetnek a kód újrahasznosítására: tu- 
lajdonképpen az alprogram-könyvtárak objektumközpontú megfelelői. 


Elképzelhető, hogy az elemkészlet-tervezést nehezebbnek találjuk, mint az alkalmazáster- 
vezést, mivel az elemkészleteknek sok alkalmazásban kell tudniuk működni, hogy használ- 
hatók legyenek. Továbbá az elemkészlet írója nincs abban a helyzetben, hogy tudná, me- 
lyek lesznek a felhasználó alkalmazások, vagy mik lesznek a különleges igényeik. Ez még 
fontosabbá teszi, hogy elkerüljük a feltevéseket és függőségeket, amik korlátozzák az 
elemkészlet rugalmasságát, és ebből következően az alkalmazás hatékonyságát. 





Keretrendszerek 

A keretrendszer (framework) együttműködő osztályok összessége egy bizonyos programtípus 
számára IDeu89, JF88], amelyek egy újrahasznosítható szerkezetben egyesülnek. Például egy 
keretrendszer irányulhat arra, hogy grafikus szerkesztőket építsünk belőle olyan különböző 
területekre, mint például a művészi rajzolás, a zeneszerkesztés, és a gépészeti CAD IVL90, 
Joh92]. Egy másik keretrendszer segíthet különböző programozási nyelvek és célgépek fordí- 
tójának megépítésében [JML92]. Megint egy másik pénzügyi modellező alkalmazások készíté- 
sét segítheti IBE93]. A keretrendszert úgy kell testreszabnunk egy adott alkalmazáshoz, hogy 
alkalmazásfüggő alosztályokat származtatunk a keretrendszer elvont osztályaiból. 


A keretrendszer meghatározza az alkalmazás felépítését. Meghatározza az általános szerke- 
Zetet, annak osztályokra és objektumokra bontását, illetve a kulcskötelességeket, vagyis 
hogy hogyan működnek együtt az objektumok és osztályok, valamint a vezérlés haladási 
irányát. A keretrendszer mindeme tervezési paramétereket előre megadja, hogy nekünk, az 
alkalmazás tervezőinek, illetve megvalósítóinak csak az alkalmazás lényegére kelljen fi- 
gyelnünk. A keretrendszer azokat a tervezési döntéseket foglalja magába, amelyek az adott 
felhasználási területen általánosak. A keretrendszerek tehát a tervezési újrahasznosítást ré- 
szesítik előnyben a kód újrahasznosításával szemben, bár egy adott keretrendszer konkrét 
alosztályokat is biztosít számunkra, amelyeket azonnal használhatunk is. 

Az ilyen szintű újrahasznosítás a vezérlés irányának megfordulásához vezet az alkalmazás 
és a program között, amelyen alapul. Ha elemkészletet használunk (vagy éppen egy ha- 
gyományos alprogram-könyvtáraD, megírjuk az alkalmazás vázát, és meghívjuk a kódot, 
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amit fel akarunk használni. Ha keretrendszert használunk, a vázat használjuk fel, és megír- 
juk a kódot, amit hív. Konkrét nevekkel és hívási módokkal rendelkező műveleteket kell ír- 
nunk, de ez lecsökkenti a tervezési döntések számát, amiket meg kell hoznunk. 


Eredményképp nem csak gyorsabban építhetjük fel alkalmazásainkat, de azoknak hasonló 
esz a szerkezetük is, egyszerűbb lesz a karbantartásuk, és következetesebbnek tűnnek 
a felhasználóknak. Másrészről veszítünk a kreatív szabadságból, hiszen már sok tervezői 
döntést meghoztak helyettünk. 


Ha az alkalmazásokat nehéz megtervezni és az elemkészleteket még nehezebb, akkor a ke- 
retrendszereket a legnehezebb. A keretrendszer-tervező arra törekszik, hogy az adott szer- 
ezet a terület minden alkalmazásának esetében működőképes legyen. Minden jelentős 
változtatás a keretrendszer szerkezetében jelentősen csökkenti a keret előnyeit, mivel an- 
nak lényege éppen az a felépítés, amit az alkalmazások számára meghatároz. Ezért életbe- 
vágó a keretrendszerek olyan rugalmasságúra és bővíthetőre írása, amennyire csak lehet. 





Továbbá, mivel az alkalmazások szerkezete annyira függ a keretrendszertől, azok különö- 
sen érzékenyek a keretrendszer felületében végrehajtott változásokra. Ahogy egy keretrend- 
szer fejlődik, az alkalmazásoknak is követniük kell. Ez teszi a laza csatolást a legfontosabbá; 


máskülönben a keretrendszer kis változtatása is jelentős kellemetlen utóhatásokat váltana ki. 





Az imént említett tervezési kérdések nagyon fontosak a keretrendszerek tervezésében. Egy 
tervezési mintán keresztül dolgozó keretrendszer sokkal valószínűbb, hogy magas szintű 
tervezést és kód-újrahasznosítást ér el, mint egy olyan, amelyik nem. A kész keretrendsze- 
rekben általában több tervezési minta is megtestesül. A minták segítségével a keretrendszer 
felépítése számos különböző alkalmazáshoz megfelel újratervezés nélkül. 


Még jobb, ha a keretrendszert a benne foglalt tervezési mintákkal együtt dokumentálják 
[BJ94]. Azok, akik ismerik a mintákat, így gyorsabban nyernek betekintést a keretrendszer- 
be, de azok is nyerhetnek a keretrendszer dokumentációjához csatolt szerkezetből, akik 
nem ismerik a mintákat. A dokumentáció elkészítése mindenféle program esetében fontos, 
de különösen a keretrendszereknél. A keretrendszerek működésének megértése gyakran 
igen nehéz, de e tudás elsajátítása szükséges ahhoz, hogy hasznosíthassuk őket. Bár a ter- 
vezési minták nem mentesítenek eme erőfeszítéstől, megkönnyíthetik a dolgunkat azzal, 
hogy egyértelműbbé teszik a keretrendszer szerkezetének elemeit. 


Mivel a minták és keretrendszerek között elég sok a közös vonás, sokan elgondolkodhat- 
nak azon, hogy mik is a különbségek, ha vannak ilyenek egyáltalán. Nos, három fő vonás- 
ban különböznek: 


1. A tervezési minták elvontabbak a keretrendszereknél. A keretrendszerek megteste- 
sülhetnek programkód formájában, de a mintáknál csak a példa jelenhet meg kód- 
ként. A keretrendszerek erőssége, hogy leírhatók programozási nyelvek segítségé- 
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vel, és nem csak tanulhatók, hanem közvetlenül futtathatók és felhasználhatók. Ez- 
zel szemben az ebben a könyvben szereplő tervezési mintákat mindig alkalmaznunk 
kell felhasználásukhoz, emellett a tervezési minták elmagyarázzák a terv céljait, elő- 
nyeit és következményeit is. 

2. A tervezési minták kisebb szerkezeti elemek a keretrendszereknél. Egy keretrendszer 
általában több tervezési mintát tartalmaz, de ez fordítva soha nem igaz. 

3. A tervezési minták kevésbé specializáltak a keretrendszereknél. A keretrendszerek 
mindig egy bizonyos felhasználási területre vonatkoznak. Egy grafikus szerkesztő 
keretrendszerét fel lehet használni egy gyár modellezésében, de ettől még nem ke- 
verhető össze egy szimulációs keretrendszerrel. Ezzel szemben az itt leírt tervezési 
mintákat szinte bármilyen alkalmazásban használhatjuk. Bár természetesen lehetne 
a mieinknél szakosodottabb tervezési mintákat készíteni (mondjuk elosztott rend- 
szerekhez vagy párhuzamos programozáshoz), még ezek sem jelölnék ki úgy az al- 
kalmazás felépítését, mint egy keretrendszer. 





A keretrendszerek egyre gyakoribbá és fontosabbá válnak. Az objektumközpontú rendszerek 
így érik el a legnagyobb felhasználhatóságot. A nagyobb objektumközpontú alkalmazások 
keretrendszerek egymással együttműködő rétegeiből állnak. Az alkalmazás szerkezetének és 
kódjának nagy része keretrendszerekből származik, vagy legalábbis ezek erősen hatnak rá. 





1.7 Hogyan válasszunk tervezési mintát? 


A katalógusban található, húsznál is több választható tervezési mintából nem könnyű meg- 
találni, melyikre van éppen szükségünk egy adott probléma megoldásához, különösen, ha 
a gyűjtemény új és ismeretlen számunkra. Ezért az alábbiakban néhány tanácsot adunk 
a megfelelő tervezési minta kiválasztásához: 





s Vegyük figyelembe, hogy a tervezési minták hogyan oldják meg a tervezési problémá- 
kat. Az 1.6-os rész azt tárgyalja, hogy a tervezési minták hogyan lehetnek segítségünk- 
re a megfelelő objektumok megtalálásában, az objektum-részletezettség és az objek- 
tumfelületek meghatározásában és más módszerekben, amelyekkel a tervezési minták 
megoldhatják gondjainkat. Ezek áttekintése segíthet a helyes minta megtalálásában. 

e Nézzük át a célról szóló részeket. Az 1.4 rész felsorolja a könyvben szereplő minták cél- 
jait. Olvassuk át ezt a részt, azok után a célok kutatva, amelyek kapcsolódnak az adott 
problémához. Az 1.1-es táblázatban található osztályozó rendszer használatával leszű- 
kíthetjük a keresést. 

. Tanulmányozzuk a minták kapcsolatát. Az 1.1-es ábra grafikusan mutatja be a terve- 
zési minták közti kapcsolatokat. Ezen kapcsolatok tanulmányozása segíthet a jó min- 
ta vagy mintacsoport megtalálásában. 

. Tanulmányozzuk a hasonló célű mintákat. A katalógus három fejezetből áll: az első 
a létrehozási mintákról szól, a második a szerkezeti mintákról, a harmadik pedig a vi- 
selkedési mintákról. Minden fejezet a mintákat bemutató megjegyzésekkel indít, és 
egy olyan résszel zárul, ami összehasonlítja a mintákat. Ezek a részek a hasonló célú 
minták közti hasonlatosságokba és különbségekbe engednek betekintést. 
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e Vizsgáljuk meg az újratervezés okait. Vizsgáljuk meg ismét az újratervezés okait a Vál- 
tozásra tervezve részben, hogy lássuk, melyik vonatkozik ránk. Aztán nézzük át a min- 
tákat, amelyek segíthetnek elkerülni az újratervezést. 

e Gondoljuk át, mit tegyünk változtathatóvá rendszerünkben, Ez a megközelítés az új- 
ratervezés okaira való összpontosítás ellentéte. Ahelyett, hogy azt néznénk, mi miatt 
kellhet megváltoztatnunk a tervet, azon gondolkodunk el, hogy mit akarunk majd újra- 


tervezés nélkül módosíthatóvá tenni. Itt a változó elemek egységbe zá. 





összpon- 


tosítunk, ami számos tervezési minta témája. Az 1.2-es táblázat azokat az elemeket so- 
































rolja fel, amelyeket az egyes tervezési minták használatával függetlenül, vagyis újrater- 
vezés nélkül megváltoztathatunk. 
Cél Tervezési minta Változtatható elemek 
Elvont gyár Leszármazott objektumok családjai 
Építő Hogyan készül az összetett objektum 
Létrehozási Gyártófüggvény Egy példányobjektum alosztálya 
Prototípus Egy példányobjektum osztálya 
Egyke Egy osztály egyetlen példánya 
Illesztő Felület egy objektumhoz 
Híd Egy objektum megvalósítása 
Összetétel Egy objektum szerkezete és összetétele 
a Díszítő Egy objektum kötelességei leszármaztatás nélkül 
Szerkezeti Homlokzat Felület egy alrendszerhez 
Pehelysúlyú Objektumok tárolásának költsége 
Helyettes Hogyan érünk el egy objektumot; 
az objektum helyzete 
Felelősséglánc Az objektum, ami a kérelmeket teljesíti 
Parancs Mikor és hogyan teljesül egy kérelem 
Értelmező Egy nyelv szabályai és értelmezése 
Bejáró Hogyan érjük el és járjuk be egy aggregátum 
elemeit 
Közvetítő Mely objektumok hatnak egymásra, 
és hogyan 
Emlékeztető Milyen privát információ tárolódik az objek- 
fi s tumon kívül, és mikor 
Viselkedési Megfigyelő Számos más objektumtól függő objektum; 
hogyan maradnak a függő objektumok 
. naprakészek 
Állapot Egy objektum állapotai 
Stratégia Egy algoritmus 
Sablonfüggvény Egy algoritmus lépései 
Látogató Olyan műveletek, amelyek alkalmazhatók 
objektum(ok)ra az osztályuk megváltoztatása 
nélkül 
1.2 táblázat 


A tervezési minták által megengedett változtatható elemek. 
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1.8 Hogyan használjuk a tervezési mintákat? 


Ha már kiválasztottuk a tervezési mintát, hogyan használjuk? Íme egy útmutató, amely lé- 
pésről lépésre megmutatja, hogyan használhatjuk fel hatékonyan a mintákat: 


x 8 


Olvassuk át a mintát, hogy legyen róla elképzelésünk. Legyünk különös figyelemmel 
az Alkalmazhatóság és a Következmények részekre, hogy biztosak lehessünk benne, 
hogy ez a megfelelő minta a problémánk megoldására. 

Térjünk vissza a Szerkezet, a Résztvevők és az Együttműködés Jejezetekre. Győződ- 
jünk meg róla, hogy értjük a mintában szereplő osztályokat és objektumokat, és 
hogy azok hogyan kapcsolódnak egymáshoz. 

Nézzük át a Példakód részt, hogy lássunk egy konkrét példát a minta kódba ágya- 
zására. A kód tanulmányozása segít a minta megvalósításának megtanulásában. 
Válasszunk olyan neveket a minta résztvevőinek, amelyek értelmesek lesznek az al- 
kalmazott környezetben. A tervezési mintákban található nevek általában túl elvon- 
tak ahhoz, hogy egy alkalmazásban használhatók legyenek. Mindazonáltal hasznos 
a résztvevő nevének belefoglalása abba a névbe, ami majd az alkalmazásban megje- 
lenik. Ennek segítségével nyilvánvalóbbá válik a minta alkalmazása a megvalósítás- 
ban. Például ha a Stratégia mintát használjuk egy szövegszerkesztő algoritmushoz, 
akkor olyan osztályaink lehetnek, mint például az EgyszerűElrendezéssStratégia vagy 
a TeXElrendezésstratégia. 

Határozzuk meg az osztályokat. Adjuk meg a felületüket, és hozzuk létre az öröklő- 
dési kapcsolataikat, majd határozzunk meg olyan példányváltozókat, amik mutatják 
az adat- és objektumhivatkozásokat. Azonosítsuk az alkalmazás azon létező osztá- 
lyait, amelyekre hatással lesz a minta, és ennek megfelelően módosítsuk azokat. 
Adjunk az alkalmazásra jellemző neveket a mintában szereplő műveleteknek. Itt 
a nevek újra csak az alkalmazástól függnek. Használjuk a műveletekhez rendelt fel- 
adatokat és együttműködési kapcsolatokat útmutatóként. Továbbá legyünk követke- 
zetesek az elnevezési rendszert illetően. Például egy gyártófüggvény nevében hasz- 
náljuk mindig a , Létrehoz-" (vagy Create) előtagot. 

Valósítsuk meg a mintában található feladatokat és együttműködéseket ellátó műve- 
leteket. A Megvalósítás rész tippeket ad a megvalósításra, de a Példakód részben leírt 
példák is segíthetnek. 








Ezek persze csak tanácsok a kezdéshez. Idővel mindenkinek kifejlődik a saját munkamód- 
szere a tervezési minták használatára. 


A tervezési minták használatának tárgyalása nem lenne teljes anélkül, hogy arról is írnánk, 
hogyan ne használjuk őket. Nos, ne használjuk őket megfontolatlanul. Gyakran úgy érnek 
el rugalmasságot és változtathatóságot, hogy további közvetítő szinteket vezetnek be, ám 
ez bonyolíthatja a szerkezetet, illetve csökkentheti a hatékonyságot. Egy tervezési mintát 
csak akkor alkalmazzunk, ha a rugalmasság, amit nyújt, valóban szükséges. A Következmé- 
nyek rész segíthet a legtöbbet egy minta előnyeinek és hátrányainak kiszámításában, 
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Ebben a fejezetben egy grafikus (WYSIWYG, , Azt kapod, amit látsz") szövegszerkesztő fel- 
építését vizsgáljuk meg, amelynek neve Lexi". Elemzésével látni fogjuk, milyen megoldáso- 
kat adnak a tervezési minták az ilyen és ehhez hasonló programok készítése során felmerü- 
lő tervezési problémákra. A fejezet végére nyolc minta gyakorlati használatában szerzünk 
jártasságot. 


A 2.1 ábra a Lexi felhasználói felületét mutatja. Az ablak közepének nagy részét egy tégla- 
lap alakú terület foglalja el, amelyben a dokumentum grafikus megjelenítése kap helyet. 
A dokumentumban szöveges részek és képek vegyesen lehetnek, különféle formázási be- 
állítások mellett. A dokumentumterületet a szokásos lenyitható menük és gördítősávok sze- 
gélyezik, illetve oldalikonok, amelyek azt szolgálják, hogy a dokumentum adott oldalára 
ugorhassunk. 


2.1 Tervezési problémák 


A Lexi szerkezetét hétféle szempontból vizsgáljuk: 


1. Dokumentumszerkezet. A dokumentum belső ábrázolásának megválasztása a prog- 
ram szerkezetének szinte valamennyi elemét érinti, hiszen minden szerkesztési, for- 
mázási, megjelenítési és szövegelemzési művelet ezen ábrázolás bejárását igényli. 
Az, ahogyan a dokumentumban levő adatokat elrendezzük, az alkalmazás többi ré- 
szének megtervezésére is kihat. 

2. Formázás. Hogyan rendezi sorokba és hasábokba a Lexi a szöveget és képeket? Mi- 
lyen objektumok felelnek a különböző formázási módok érvényre juttatásáért? Ho- 
gyan kapcsolódnak ezek a formázási módok a dokumentum belső ábrázolásához? 

3. A felhasználói felület finomítása. A Lexi felhasználói felülete gördítősávokat, szegé- 
lyeket és árnyékolásokat tartalmaz, amelyek a grafikus dokumentummegjelenítést 





! A Lexi szerkezete a Doc-on alapul, amely egy szövegszerkesztő alkalmazás, amelyet Calder [CL92] készített. 
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4. 


teszik szebbé. Ezek a díszítő elemek valószínűleg változni fognak, ahogy a felhasz- 
nálói felületet továbbfejlesztjük, ezért fontos, hogy anélkül legyenek könnyen eltá- 
volíthatók, illetve kiegészíthetők, hogy ez a program többi részét érintené. 

Több megjelenítési szabvány támogatása. Célunk, hogy a Lexi könnyen alkalmaz- 
kodjon az olyan különböző megjelenítési szabványokhoz, mint a Motif vagy a Pre- 
sentation Manager (PM), és ehhez ne legyen szükség nagyobb módosításokra. 

Több ablakkezelő rendszer támogatása. A különféle megjelenítési szabványok általá- 
ban többféle ablakkezelő rendszeren működnek. A Lexit annyira függetleníteni kell 
az ablakrendszerektől, amennyire csak lehetséges. 

Felhasználói műveletek. A felhasználók különféle grafikus felületi elemeken — gom- 
okon, lenyíló menükön stb. — keresztül vezérelhetik a programot, melyek működé- 
sét az alkalmazás különböző részein szétszórt objektumok biztosítják. A kihívást az 
jelenti, hogy egységesen kezeljük ezeket az objektumokat, illetve egységesen von- 
nassuk vissza az általuk végrehajtott műveleteket. 

Helyesírás-ellenőrzés és elválasztás. Hogyan támogatja a Lexi az olyan elemző művele- 
teket, mint a helytelenül írt szavak megkeresése vagy az elválasztási pontok meghatá- 
rozása? Hogyan csökkenthetjük a lehető legkisebbre azon osztályok számát, amelye- 
ket módosítanunk kell, ha új elemző művelettel szeretnénk kiegészíteni a programot? 
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2.1 ábra 
A Lexi felhasználói felülete. 
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A fenti tervezési problémákat a következő részekben alaposabban megvizsgáljuk. Mind- 
egyikhez célokat kapcsolunk, illetve megszorításokat, amelyek az említett célok elérésének 
módjára vonatkoznak. Először részletesen elmagyarázzuk a célokat és megszorításokat, és 
csak ezután térünk rá a megoldási javaslatokra. Egy-egy probléma és megoldása egy vagy 
több tervezési mintát mutat be; a problémák felvázolása minden esetben a vonatkozó ter- 
vezési minta rövid bevezetésével zárul. 


2.2 Dokumentumszerkezet 


A dokumentum végső soron nem más, mint alapvető grafikai elemek — karakterek, vona- 
lak, sokszögek és más alakzatok — adott elrendezése. Ezek az elemek határozzák meg a do- 
kumentum teljes információtartalmát, de a dokumentum készítője nem grafikai, hanem a fi- 
zikai szerkezethez kapcsolódó elemekként — sorok, hasábok, ábrák, táblázatok és más 
szerkezetek — látja azokat, amelyek maguk is kisebb hasonló elemekből állnak. 





A Lexi felhasználói felületét úgy kell elkészítenünk, hogy a programot használók képesek 
legyenek ezeket az elemeket közvetlenül elérni. Nem árt például, ha a felhasználó egy di- 
agramot egységként és nem önálló grafikai alapelemek (primitívek) halmazaként kezelhet, 
vagy ha egy táblázatra mint egészre és nem mint képekkel kevert szövegek alaktalan 
masszájára hivatkozhat. Ettől lesz a felület egyszerű és könnyen használható. Ahhoz, hogy 
ezt a Lexi esetében is elérhessük, olyan belső ábrázolást választunk, ami illeszkedik a doku- 
mentum fizikai szerkezetéhez. 





A belső ábrázolásnak konkrétan az alábbiakat kell támogatnia: 


s A dokumentum fizikai szerkezetének megőrzése, vagyis a szövegek és képek sorok- 
ba, hasábokba, táblázatokba stb. rendezése. 

s A dokumentum grafikus képének előállítása és megjelenítése. 

s A megjelenített kép pontjainak megfeleltetése a belső ábrázolás elemeinek. Ez teszi 
lehetővé, hogy a Lexi meghatározza, mire is hivatkozik a felhasználó, amikor a do- 
kumentum grafikus megjelenítésén belül valahová kattint. 





E célok elérésében bizonyos megkötéseket kell tennünk. Először is, a képeket és szövege- 
ket egységesen kell kezelnünk. Az alkalmazás meg kell, hogy engedje a felhasználónak, 
hogy szöveget illesszen be képbe és fordítva. El kell kerülnünk, hogy a képeket a szöveg 
különleges eseteként kezeljük, vagy a szövegeket különleges képként, másképp felesleges 
szerkesztő és formázó műveletekkel fogunk rendelkezni. Egyetlen művelethalmaz elegen- 
dő kell legyen mind a szövegekhez, mind a képekhez. 





? A dokumentumok készítői emellett gyakran a logikai szerkez 
mondatok, bekezdések, f. 
használt belső ábrázol 
oldá 





t alapján gondolnak a dokumentumra, vagyis mint 






etek és alfejezetek összességére. A példa egyszerűsítése érdekében az általunk 
etten nem tárol majd információt a logikai szerkezetről, bár a leírt tervezési meg- 
az ilyen információk ábrázolására is tökéletesen alkalmas. 
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Másodszor, a belső ábrázolás megvalósításában az önálló elemek és elemcsoportok között 
nem szabad különbséget tennünk. A Lexi képes kell legyen arra, hogy az egyszerű, illetve 
összetett elemeket egységesen kezelje, és így támogassa a tetszőlegesen összetett doku- 
mentumokat. , A második hasáb ötödik sorában a tizedik elem? lehessen egyetlen karakter, 
de számos alelemmel rendelkező bonyolult diagram is. Amíg az elem megrajzolhatja magát 
és meghatározhatjuk kiterjedését, bonyolultsága nem lesz hatással arra, hogy az oldalon 
hol és hogyan jelenik meg. 


A második megszorítással szemben azonban a szöveget abban az esetben igenis elemez- 
nünk kell, ha helyesírási hibákat és elválasztási pontokat keresünk. Sokszor nem számít, 
hogy egy sor egy eleme egyszerű vagy összetett objektum-e, máskor azonban az elemzés 
az adott objektum típusától függ. Nincs értelme például egy sokszög helyesírását ellenőriz- 
ni vagy elválasztani azt. A program belső szerkezetének ezeket és más ellentmondó meg- 
szorításokat is figyelembe kell vennie. 


Onhívó felépítés 

A hierarchikus felépítésű információk ábrázolásának egyik elterjedt módja az önhívó felépítés 
(rekurzív kompozíció), melynek során egyszerű elemekből egyre összetettebbeket építünk 
fel. E módszer révén a dokumentum egyszerű grafikai elemekből állítható össze. Első lé- 
pésként karakterek és képek halmazát rakhatjuk sorba balról jobbra, hogy kialakítsunk egy 
sort, Aztán több sort hasábba rendezhetünk, a hasábokból oldalakat építhetünk és így to- 
vább (ásd a 2.2 ábrán. 


karakter térköz kép összetétel (sor) 
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összetétel (hasáb) 


2.2 ábra 
Képek és szöveg önhívó felépítése. 
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2.3 ábra 
Képek és szöveg önhívó felépítésének objektumszerkezete. 














Draw(Window) 
Intersects(Point) 
Insert(Glyph, int) 
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w-5 DrawCharacterf(c) 




















2.4 ábra 
Részleges képjel-osztályhiererchia. 
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A fizikai szerkezetet úgy ábrázolhatjuk, hogy minden lényeges eleméhez egy objektumot 
rendelünk. Tehát nem csak a látható elemekhez, amilyenek a karakterek és képek, hanem 
a láthatatlan szerkezeti elemekhez, a sorokhoz és hasábokhoz is. Az eredményt a 2.3 ábrán 
átható objektumszerkezet mutatja. 


Azzal, hogy a dokumentum minden karakteréhez és grafikus eleméhez egy-egy objektu- 
mot társítunk, a Lexi szerkezetének minden szintjén biztosítjuk a rugalmasságot. A szövege- 
ket és képeket megrajzolásukat, formázásukat és egymásba való ágyazottságukat figyelem- 
be véve, egységesen kezelhetjük. A programot új karakterkészletek támogatásával is kiegé- 
szíthetjük, anélkül, hogy ez érintené a többi szolgáltatást. A Lexi objektumszerkezete a do- 
kumentum fizikai szerkezetét modellezi. 


Ez a megközelítés két dolgot von maga után. Az első nyilvánvaló: az objektumhoz megfele- 
ő osztályokat kell létrehoznunk. A második, ami már nem biztos, hogy annyira magától ér- 
tetődő, hogy ezek az osztályok összeegyeztethető felületeket igényelnek, hiszen az objek- 
tumokat egységesen szeretnénk kezelni. Összeegyeztethető felületeket pedig egy olyan 
nyelvben, mint a C---, úgy készíthetünk, ha az osztályokat öröklés útján származtatjuk. 


Képjelek 
A dokumentumszerkezetben megjelenő valamennyi objektum közös elvont osztálya a Kép- 
jel CGlyph?) lesz. Alosztályai mind egyszerű grafikai elemeket (karakterek, ké pek), mind 
szerkezeti elemeket (sorok, hasábok) leírnak majd. A 2.4 ábra a Képjel (az ábrán angolul 
Glyph) osztályhierarchia egy jellemző részletét mutatja, míg a 2.1 táblázatban a Cr jelölé- 
sét használva részletesebben is bemutatjuk az alapvető képjelfelületeté. 








Felelősségi kör Műveletek 





virtual void Draw(Windowr ) 


Megjelenés 
g] virtual void Bounds(Rectf) 





Találat-érzékelés virtual bool Intersects(const Point6) 





virtual void Insert(Glyph", int) 
virtual void Remove (Glyphr") 
virtual Glyphr Child(int) 
virtual Glyphr Parent() 


Szerkezet 














2.1 táblázat 
Alapvető képjelfelület. 





3 A sglyph" kifejezést ebben az összefüggésben először Calder ICL90] használta; a mai szövegszerkesztők többsé- 
ge nem használ minden karakterre külön objektumot, valószínűleg hatékonysági okokból. Calder tanulmányá- 
ban [Cal93] bizonyította, hogy a megoldás működőképes. A mi képjeleink az övéinél kevésbé kifinomultak, mert 
az egyszerűség kedvéért szigorú hierarchiába rendeztük őket. Calder glyph-jei a tárolási költségek csökkentése 
végett megoszthatók, így irányított körmentes gráf szerkezetet formálnak. A Pehelysúlyú minta használatával ha- 
sonló eredményt érhetünk el, de ezt meghagyjuk gyakorló feladatnak. 


§ Az itt leírt felületet szándékosan egyszerűsítettük le a végletekig, hogy magyarázatunk követhető legyen. Egy tel- 
jes felület az olyan grafikus jellemzők kezelésére szolgáló műveleteket is tartalmazná, mint a szín vagy a betűű- 
pus, illetve képes lenne koordináta-átalakításra, és magába foglalna bonyolultabb gyermekkezelő eljárásokat is. 
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A képjeleknek három alapvető feladatuk van. 1. Tudniuk kell, hogyan rajzolják meg önmagu- 
kat. 2. Tudniuk kell, mennyi helyet foglalnak. 3. Ismerniük kell a szülőjüket és gyermekeiket. 


A Glyph alosztályai felülbírálják a Draw (Rajzol) műveletet, így rajzolják ki magukat az ab- 
lak felületére; a Draw hívása során egy Window (Ablak) objektumra való hivatkozást kap- 
nak. A Window osztály határozza meg azokat a grafikai műveleteket, amelyek a szövegek és 
más alapvető alakzatok képernyőre rajzolásához szükségesek. A Glyph Rectangle (Tégla- 
lap) alosztálya például a következőképpen írhatja felül a Draw műveletet: 


void Rectangle::Draw (Windowt w) ( 
w-sDrawRect( x0, .Y0, xi, .y1); 
) 


A fentikódbanaz x0, y0O, xlés y1aPRectangle adattagjai, amelyek a téglalap két el- 
entétes sarkának koordinátáit írják le, a DrawRect pedig a Window-nak azon művelete, 
amely a téglalapnak a képernyőn való megjelenítéséért felelős, 


A szülő képjeleknek gyakran tudniuk kell, mekkora helyet foglal egy adott gyermekük, 
hogy azt más képjelekkel együtt úgy rendezhessék sorba, hogy egyik se fedje a másikat. 
(Erre mutat példát a 2.2 ábra.) A képjel által elfoglalt téglalap alakú területet a Bounds (Ha- 
tárok) művelet adja vissza, azon legkisebb befoglaló négyszög ellentétes sarkainak koordi- 
nátáival, amelyekbe a képjel még belefér. A Glyph alosztályai ezt a műveletet bírálják felül, 
10gy meghatározhassák a saját rajzolásukhoz szükséges területet. 





Az Intersects (Metszi) művelet azt adja meg, hogy egy adott pont metszi-e a képjelet. 
Amikor a felhasználó valahol a dokumentumban kattint, a Lexi meghívja ezt a műveletet, 
hogy meghatározza, melyik képjelen, illetve annak melyik részén történt az egérkattintás. 
A Rectangle osztály ennek felülírásával számítja ki a téglalap és az adott pont metszéspontját. 





Miután a képjeleknek gyermekeik is lehetnek, ezek hozzáadásához, elvételéhez, illetve el- 
éréséhez közös felületre van szükségünk. A Row (Sor) gyermekei például azok a képjelek, 
amelyek a sorban találhatók. Az Insert (Beillesz0 művelet egy képjelet illeszt be egy 
egész sorszám által meghatározott helyen", míg a Remove (Eltávolít) eltávolítja a megadott 
képjelet, ha az valóban gyermek. 


A Child (Gyermek) művelet a megadott sorszámon található gyermeket adja vissza (ha 
van ott olyan). A Row-hoz hasonló, gyermekekkel rendelkezni képes képjelek belsőleg 
kell, hogy használják a Child műveletet, vagyis nem jó, ha a gyermekek adatszerkezetét 


közvetlenül érik el. Így később nem kell módosítani a Draw-hoz hasonló gyermekbejáró 
műveleteket, ha az adatszerkezetet mondjuk tömbről láncolt listára változtatjuk. Ugyanígy 





5 Az egész sorszámok használata talán nem a legjobb módja annak, hogy meghatározzuk egy képjel gyermekeit, 
de ez a képjel által használt adatszerkezettől függ. Ha gyermekeit láncolt listában tárolja, egy, a listát címző mu- 
tató hatékonyabb lenne. A sorszámozás (indexelés) problémájára jobb megoldást is látunk majd a 2.8 részben, 
ahol a dokumentum elemzését tárgyaljuk. 


Programtervezési minták 





a Parent (Szülő) a képjel szülőjéhez biztosít szabványos felületet. A Lexiben a képjelek hi- 
vatkozást tárolnak a szülőjükre, Parent műveletük pedig egyszerűen ezt a hivatkozást ad- 
ja vissza. 


Az Összetétel tervezési minta 

Az önhívó összetétel módszere nem csak a dokumentumok esetében működik; bármilyen 
bonyolult, hierarchikus felépítményt ábrázolhatunk vele. A módszer objektumközpontú fo- 
galmakkal vázolt lényegét az Összetétel (Composite) minta ragadja meg — tulajdonképpen 
itt is az ideje, hogy közelebbről megvizsgáljuk e mintát, szükség esetén visszautalva az itt 
bemutatott forgatókönyvre. 


2.3 Formázás 


Már eldöntöttük, hogyan ábrázoljuk a dokumentum fizikai szerkezetét; így a következő lé- 
pés, hogy kitaláljuk, hogyan építhetünk fel egy konkrét szerkezetet, ami megfelel egy he- 
lyesen formázott dokumentumnak. Az ábrázolás és formázás között különbséget kell ten- 
nünk: attól, hogy képesek vagyunk ábrázolni a dokumentum fizikai szerkezetét, még nem 
tudjuk, hogyan készíthetünk el egy adott szerkezetet. Ez nagyrészt a Lexi feladata lesz: 
a szöveget sorokra kell tördelnie, a sorokat hasábokba és így tovább, figyelembe véve a fel- 
használó kívánságait. A felhasználó például változtatható margószélességet, behúzást és 
térközöket, egyes és kettes sortávot, esetleg más formázási lehetőségeket szeretne", ame- 
lyeket a Lexi formázó algoritmusának mind figyelembe kell majd vennie. 


,Formázás" alatt mi most csupán azt fogjuk érteni, hogy képjelek csoportját sorokba ren- 
dezzük, vagyis a , formázás" és , sortörés" kifejezéseket felcserélhetjük. A tárgyalt eljárás s0- 
rok hasábokba, illetve hasábok oldalakra rendezésére is ugyanúgy alkalmas. 























Felelősségi kör Műveletek 
Mit formázunk? void SetComposition(Compositiont) 
Mikor formázunk? virtual void Compose() 
2.2 táblázat 


Egyszerű összeállító felület. 





§ A felhasználót még ennél is jobban érdekelheti a dokumentum /ogikai szerkezete, vagyis a mondatok, bekezdé- 
sek, fejezetek, alfejezetek stb. A fizikai szerkezet ezzel összehasonlítva kevésbé lényeges: a legtöbb embert nem 
érdekli, hogy egy bekezdésben hová esnek a sortörések, amíg a bekezdés formázása megfelelő, és ugyanez ér- 


vényes a hasábok és oldalak formá. 
szerkezetet illetően, és a Lexire bízz; 






sára is. Tehát a felhasználó csupán magas szintű megkötéseket tesz a fizikai 
, hogyan elégíti ki az igényeket. 
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A formázó algoritmus egységbe zárása 


A formázási folyamatot, megszorításaival és más részleteivel együtt, nehéz automatizálni. 
A problémára számos megközelítés létezik, és a programozók különböző hatékonyságú 
formázó algoritmusok egész sorát dolgozták ki. Miután a Lexi vizuális szerkesztő, az egyik 
lényeges kérdés, amelyben kompromisszumot kell kötnünk, hogy melyik fontosabb: a for- 
mázás minősége vagy a sebessége? Általában azt várjuk el, hogy a szerkesztő viszonylag 
gyorsan hajtsa végre utasításainkat, de anélkül, hogy ez a dokumentum külalakján különö- 
sebben rontana. Ennek megoldása számos tényező függvénye, amelyek közül nem mind- 
egyik befolyásolható fordítási időben. Előfordulhat, hogy a felhasználó a szebb megjelení- 
tést részesíti előnyben, és ennek érdekében hajlandó elnézni a némileg lassabb működést, 
ami esetleg teljesen más algoritmus használatát igényli, mint az, amit éppen alkalmazunk. 
Egy másik, a megvalósítás módjára nagyobb hatást gyakorló döntés lehet, hogy a formázás 
sebességét vagy a tárigényt tartjuk inkább szem előtt. A formázás végrehajtására fordított 
idő csökkenthető, ha több információt tárolunk átmenetileg. 





A formázó algoritmusok általában bonyolultak, ezért kívánatos, hogy minél jobban függet- 
lenítsük azokat a dokumentum szerkezetétől. Ideális esetben anélkül hozhatunk létre új 
képjeleket, hogy a formázó algoritmusra figyelnünk kellene, és fordítva, egy új formázó al- 
goritmus hozzáadása sem lenne szabad, hogy a meglevő képjelek módosításának szüksé- 
gességét vonja maga után. 








A fenti szempontokból következik, hogy a Lexit úgy kell megterveznünk, hogy a formázó 
algoritmust legalább fordításkor, de lehetőség szerint akár futásidőben lecserélhessük. 
Az algoritmus elszigetelését és egyszersmind könnyű cserélhetőségét úgy biztosíthatjuk, ha 
egy objektumba tokozzuk be, pontosabban ha külön osztályhierarchiát hozunk létre azon 
objektumok részére, amelyek formázó algoritmusokat zárnak egységbe. A hierarchia csú- 
csán egy felület fog állni, ami formázó algoritmusok széles körét támogatja, alosztályai pe- 
dig ezt a felületet valósítják majd meg egy-egy algoritmus működtetéséhez. Ezután már 
nincs akadálya, hogy bevezessünk egy Glyph alosztályt, amely gyermekeit egy adott algo- 
ritmus objektum használatával rendezi. 


Osszeállítók és összetételek 

Először is készítünk egy Összeállító (Compositor) osztályt azon objektumok számára, ame- 
lyek egységbe zárhatnak egy formázó algoritmust. A felület (2.2 táblázat) tudatja az összeál- 
lítóval, mely képjeleket kell formázni, és mikor. A formázandó képjelek az Összetétel 
(Composition) nevű különleges Képjel (Glyph) alosztály gyermekei. Az Összetétel osztály 
példányai létrehozásukkor megkapják az Összeállító alosztály egy példányát (amelyik az 
adott sortörési algoritmusra szakosodott), amelyet arra utasítanak, hogy a Compose (Össze- 
állín művelettel szükség esetén — például ha a felhasználó módosította a dokumentumot — 
rendezzék a képjeleket. A 2.5 ábra az Összetétel (Composition) és az Összeállító (Compo- 
sitor) osztályok közötti viszonyokat mutatja. 
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Glyph 





Insert(Giyph, int) 











gyermekek összeállító Compositor 
vo Composition ————— 
Fárzadzasészássazt ll zetett szttsztátázal Compose() 


Insert(Glyph g, inti) 2 SetComposiítion() 
kssismzzetátezeáügkezésászőltk 
1 
, 
Glyph:Insert(g, i) [ 


SOMAGSNAS ZATOAKST) ArrayComposítor ] TeXCompositor SimpleCompositor 














összetétel 









































Compose() ] Composet() Composet() 





2.5 ábra 
A Composition és Compositor osztályok kapcsolata. 


A formázatlan Összetétel objektumok csak azokat a látható képjeleket tartalmazzák, ame- 
lyek a dokumentum alaptartalmát alkotják. Olyan képjelek nem kapnak benne helyet, 
amelyek a dokumentum fizikai szerkezetét, például a sorokat (Row) vagy hasábokat 
(Column) határozzák meg. Most az összetételnek közvetlenül a létrehozása utáni állapotá- 
ról beszélünk, amikor is kezdetben az általa formázandó képjelekkel feltöltődik. Amikor 

zásra van szükség, az összetétel meghívja ; sz 
állító pedig végigjárja az összetétel gyermekeit és új Row és Column képjeleket illeszt be, 
sortörési algoritmusának megfelelően". Az előálló objektumszerkezetet a 2.6 ábra mutatja; 
ezen az összeállító által létrehozott és a szerkezetbe beillesztett képjeleket szürke háttérrel 
ábrázoltuk. 





Minden Összeállító alosztály más és más sortörési algoritmust valósíthat meg. Az Egyszerű- 
Összeállító (SimpleCompositor) nevű például gyors áttekintésre lehet alkalmas, ha nem nézi 
az olyan ,elhanyagolható" jellemzőket, mint a dokumentum , színe", (A dokumentum színe 
a szöveg és a térközök eloszlására utal: a jó szín" ezek egyenletességét jelenti.) A teljes TeX al- 
goritmus megvalósítására használhatunk egy TeXÖsszeállító (TeXCompositor) nevű alosztályt, 
ami a , színt" is figyelembe veszi, viszont lassabban dolgozik. 


Az Összetétel-Összeállító osztálybontás biztosítja, hogy élesen elválaszthassuk egymástól 
a dokumentum fizikai szerkezetét alakító kódot a különböző formázó algoritmusok kódjá- 
tól. Anélkül vehetünk fel a rendszerbe új Összeállító osztályokat, hogy hozzá kellene nyúl- 
nunk a képjelosztályokhoz, és fordítva. Ha egy Setcompositor (Összeállító-beállító) mű- 
veletet adunk az Összetétel képjel-alapfelületéhez, még arra is lehetőségünk lesz, hogy fu- 
tásidőben kicseréljük a sortörési algoritmust. 





7 A sortörések helyének kiszámításához az összeállítónak meg kell kapnia a karakter képjelek karakterkódjait. 
A 2.8 részben megnézzük, hogyan juthatunk hozzá ehhez az információhoz többféleképpen (a többalakúság se- 
gítségével), anélkül, hogy külön karakterműveletet adnánk a Glyph felülethez. 
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A Stratégia tervezési minta 


A Stratégia minta lényege az algoritmusok objektumokba zárása. A minta kulcselemei a Stra- 
tégia (Strategy) objektumok (amelyek a különböző algoritmusokat egységbe zárják), és ezek 
működési környezete. Az összeállítók — lévén ezek is egy-egy formázó algorimust foglalnak 
magukba - szintén Stratégia objektumok, működési környezetük pedig az Összetétel. 


A Stratégia minta alkalmazásának kulcsa olyan felületek tervezése a stratégia és környezete 
számára, amelyek elég általánosak ahhoz, hogy algoritmusok széles körét támogassák. Va- 
gyis egy új algoritmus támogatásához nem szabad, hogy a stratégia vagy a környezet meg- 
változtatására legyen szükség. Példánkban a Képjel (Glyph) alapfelület kellően általánosan 
támogatta a gyermekek hozzáadását, eltávolítását és elérését ahhoz, hogy az Összeállító al- 
osztályok az általuk használt algoritmustól függetlenül módosíthassák a dokumentum fizi- 
kai szerkezetét, és ehhez hasonlóan az Összeállító felület is megadott mindent az összetéte- 
leknek, hogy kezdeményezhessék a formázást. 








összetétel 


oO 





összeállító alkotta 
képjelek 











összeállító 


Összeállító irányította sortörést tükröző objektumszerkezet. 


2.4 A felhasználói felület finomítása 


A Lexi felhasználói felületéhez két díszítő elemet adunk: egy szegélyt a szövegszerkesztő 
területhez, ami a szövegoldalt jelzi majd, illetve az oldal különböző részeinek megtekinté- 
sét segítő gördítősávokat. Nem örökléssel adjuk ezeket a felülethez, mert azt szeretnénk, ha 


Programtervezési minták 





minél könnyebben hozzáadhatók és elvehetők lennének (különösen futásidőben). Akkor 
érjük el a legnagyobb rugalmasságot, ha a többi felhasználói felületi elem nem is tud róla, 
hogy ezek a kiegészítő objektumok léteznek, így anélkül kapcsolhatjuk ki-be őket, hogy 
más osztályokat módosítanunk kellene. 


Átlátszó befoglalás 

Programozási szempontból a felhasználói felület finomítása a meglevő kód bővítését jelen- 
ti. Ha ezt öröklés révén érjük el, megfosztjuk magunkat attól a lehetőségtől, hogy a díszítő 
elemeket futásidőben átrendezhessük, de talán ennél is fontosabb, hogy az öröklés alapú 
megközelítés az osztályok számának nemkívánatos növekedését vonhatja maga után. 


A szegélyt az Összetétel osztályból egy SzegélyesÖsszetétel (BorderedComposition) alosz- 
tályt létrehozva állíthatjuk elő, a gördítősávok felületét pedig ugyanígy, a Görgethető- 
Összetétel (ScrollableComposition) alosztály elkészítésével. Ha szegélyt és gördítősávokat 
is akarunk, egy SzegélyesGörgethetőöÖsszetétel (BorderedScrollableComposition) osztályt 
is alkothatunk és így tovább. Szélsőséges esetben a díszítés minden változatára külön osz- 
tályunk lehet, mely megoldás a díszítő elemek változatosságának növekedésével hamar 
működésképtelenné válhat. 


Az objektumösszetétel rugalmasabb és kezelhetőbb bővítési módot kínál. De milyen objek- 
tumokat párosítsunk össze? Tudjuk, hogy egy meglevő képjelet finomítunk, ezért magát 
a díszítést is objektummá tehetjük (mondjuk a Szegély — Border — osztály egy példányává), 
így az összetétel két elemből állhat elő: a képjelből és a szegélyből. A következő lépés an- 
nak eldöntése, hogy melyik elemet adjuk melyikhez. Az, hogy a szegély tartalmazza a kép- 
jelet, logikusnak tűnik, hiszen a képernyőn is a képjel lesz a szegély belsejében. De tehet- 
jük ennek ellenkezőjét is, a szegélyt ágyazva a képjelbe, ám ekkor módosításokat kell vég- 
rehajtanunk a megfelelő Glyph alosztályon, hogy az tudomással bírjon a szegély létezésé- 
ről. Az első választás tehát jobbnak tűnik, hiszen így a szegélyrajzoló kódot teljes egészé- 
ben a Border osztályon belül tarthatjuk, és nem zavarjuk a többi osztályt. 


Hogyan nézzen ki a Border osztály? Az a tény, hogy a szegély grafikusan megjelenik a kép- 
ernyőn, azt sugallja, hogy maga is képjel, így a Border a Glyph alosztálya kell legyen. Arra, 
hogy ezt tegyük, azonban van még egy okunk: a felhasználók nem törődnek azzal, hogy 
egy képjelnek van-e szegélye vagy sem, hanem egységesen szeretnék kezelni azokat. 
Ha egy szegély nélküli képjelnek azt mondják, hogy rajzolja meg magát, annak ezt minden- 
féle díszítés nélkül kell végrehajtania. Ha a képjel a szegély belsejében jön létre, a szegélyt 
is ugyanúgy kezelhetjük: arra, hogy rajzolja ki magát, ugyanúgy utasíthatjuk, mint bármely 
más képjelet. Ez mutatja, hogy a Border felületnek illeszkednie kell a Glyph felülethez; ezt 
a kapcsolatot azzal biztosítjuk, hogy a Border-t a Glyph alosztályaként hozzuk létre. 


Mindez elvezet minket az átlátszó befoglalás (láthatatlan befoglalás, transparent enclosure) 
fogalmához, amelynek alapját az (1) egyetlen gyermekes (vagy egyelemű) összetétel, illet- 
ve az (2) összeegyeztethető felületek képezik. A felhasználó programok általában nem tud- 
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ják megállapítani, hogy magával az adott elemmel vagy a befoglalójával (vagyis a gyermek 
szülőjével) kerültek-e kapcsolatba, különösen ha a befoglaló egyszerűen átruházza műve- 
leteit a befoglalt elemre. Emellett azonban a befoglaló ki is bővítheti elemének viselkedését, 
ha egy művelet átruházása előtt vagy után saját műveleteket is végez, illetve kiválóan alkal- 
mas az elem állapotának beállítására is. Hamarosan meglátjuk, hogyan. 


Monoglyph 

Az átlátszó befoglalás fogalmát bármely olyan képjellel kapcsolatban alkalmazhatjuk, ami 
egy másikat díszít. A fogalom konkretizálásához létrehozzuk a Glyph MonoGlyph nevű al- 
osztályát, amely az olyan díszítő képjelek elvont osztálya lesz, mint a Border (lásd a 2.7 áb- 
rát). A MonoGlyph egy hivatkozást tárol egy elemre, és minden kérelmet annak továbbít. 


Glyph 


Draw(Window) 


0 MonodGlyph 
elem 
Draw(Window) 




















Draw(Window) 
DrawBorder(Window) 






Draw(Window) 





2.7 ábra 
MonodGlyph osztálykapcsolatok. 


Ez a MonoGlyph-et alapállapotban teljesen észrevehetetlenné teszi a felhasználó progra- 
mok számára. A MonoGlyph például a következőképpen valósítja meg a Draw műveletet: 


void MonoGlyph::Draw (Windowt w) ( 
elem -sDraw(w) ; 


, 


A MonodGlyph alosztályai ezen továbbító műveleteknek legalább az egyikét felülírják. 
A Border : : Draw például először meghívja a szülőosztálybeli MonoGlyph : : Draw műve- 
letet az elemre, hogy az elvégezhesse a dolgát, vagyis a szegélyt leszámítva mindent kiraj- 
zoljon. Ezután a Border : : Draw a DrawBorder (RajzolSzegély) nevű privát művelet meg- 
hívásával kirajzolja a szegélyt. (Ennek részleteibe most nem megyünk bele.) 
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void Border::Draw (Windowt w) ( 
MonoGlyph: : Draw(w) ; 
DrawBorder (w) ; 

: 


Megfigyelhetjük, milyen hatékonyan bővíti kia Border : : Draw a szülőosztálybeli művele- 
tet a szegély megrajzolásához, ellentétben azzal, ha csupán lecserélné azt, amikor is 
a MonoGlyph: : Draw hívás kimaradna. 


Egy másik MonoGlyph alosztály a 2.7 ábrán látható. A Scroller (Görgető) olyan MonoGlyph, 
amely két gördítősáv alapján rajzolja ki magát különböző helyekre. Amikor a Scroller kiraj- 
zolja az elemét, a grafikus alrendszert arra utasítja, hogy a görgető határain túli részeket 
vágja le, az elem látható területről kigördített részei így nem jelennek meg a képernyőn. 


Ezzel meg is vannak azok az elemek, amelyek segítségével a Lexi szövegszerkesztő terüle- 
téhez szegélyt és gördítősávokat adhatunk. A meglevő Összetétel példányt a gördíthető fe- 
lület kialakításához egy Görgető példányban hozzuk létre, azt pedig egy Szegély példány- 
ban. Az előálló objektumszerkezet a 2.8 ábrán látható. 









2.8 ábra 
Finomított objektumszerkezet. 
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Megjegyzendő, hogy az összetétel sorrendjét meg is fordíthatjuk, vagyis a szegéllyel ellátott 
Összetételt is tehetjük egy Görgető példányba, de ekkor a szöveggel együtt a szegély is to- 
vábbgördül, ami nem biztos, hogy a kívánt viselkedés. A lényeg azonban az, hogy az átlát- 
szó befoglalás egyszerűvé teszi a különböző lehetőségekkel való kísérletezést, és a felhasz- 
náló programot megszabadítja attól, hogy a díszítő elemek kódjával foglalkoznia kelljen. 
Megfigyelhetjük azt is, hogy a szegély csupán egyetlen képjelből áll, nem kettőből vagy an- 
nál is többől. Ez az eddig bemutatott összetételektől eltér, hiszen azoknál a szülőobjektu- 
mok tetszőleges számú gyermeket tartalmazhattak. A szegély azonban egyetlen elemet fog- 
lal magába, tehát csak egyetlen ilyen lehet. Egyszerre több elemhez is adhatnánk díszítést, 
de ekkor a díszítés fogalmát többféle összetétel fogalmával — sor, hasáb stb. — kellene ke- 
vernünk, ami nem szerencsés, hiszen ezekhez már rendelkezésre állnak a megfelelő osztá- 
lyok. Jobb, ha az összetételhez a meglevő osztályokat használjuk, és a díszítést új osztá- 
lyokra bízzuk. Ezzel a külalak finomítását elválaszthatjuk a többi összetételtől, ami egyszer- 
re egyszerűsíti a díszítő osztályokat, tartja alacsonyan számukat, illetve akadályozza meg, 
hogy a már meglevő szolgáltatásokat ismételten elkészítsük. 








A Díszítő minta 

A Díszítő minta az átlátszó befoglalás segítségével ragadja meg a díszítést támogató osztály- 
és objektumkapcsolatokat. A , díszítés" fogalma persze szélesebb annál, mint ahogy eddig 
használtuk. A Díszítő mintában e fogalom mindenre vonatkozik, ami egy objektum feladat- 
körét kibővíti. Például egy elvont szintaxisfát szemantikai műveletekkel díszíthetünk, egy 
véges állapotú automatát új állapot-átmenetekkel, vagy maradandó objektumok hálóját jel- 
lemzőcímkékkel. A Díszítő minta általánosítja a Lexi kapcsán bemutatott megközelítést, 
hogy az szélesebb körben is alkalmazható legyen. 








2.5 Több megjelenítési szabvány támogatása 


A rendszertervezés egyik fő problémája, hogyan oldjuk meg a különböző hardver- és szoft- 
verfelületek közötti átjé 





t. Ha a Lexit más rendszerre szeretnénk átültetni, nyilván nem 
akarjuk, hogy ez kimerítő munkával járjon, másképp nem érné meg az egész. Más szóval: 
az átültetést olyan egyszerűvé kell tenni, amennyire csak lehetséges. 


A hordozhatóság egyik akadálya az alkalmazások egységes kinézetét biztosító megjeleníté- 
si szabványok (100k-and-feel standard) sokasága. Ezek a szabványok adnak irányelveket 
arra vonatkozóan, hogy az egyes programok hogyan jelenjenek meg és hogyan reagáljanak 
a felhasználók tevékenységére. A ma létező szabványok persze nem térnek el túlságosan 
egymástól, mégis összetéveszthetetlenek. A Motif alkalmazások például nem egészen úgy 
néznek ki, mint más rendszereken futó társaik, és azokról is elmondható, hogy más hatást 
keltenek, mint a Motif programok. Egy olyan alkalmazásnak, amely képes több rendszeren 
is futni, igazodnia kell az adott rendszerek felhasználói felületéhez. 
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Tervezési célunk, hogy a Lexit képessé tegyük arra, hogy több meglevő megjelenítési szab- 
ványhoz alkalmazkodjon, illetve hogy könnyű legyen az esetleges új szabványok támoga- 
tását is beleépíteni. Emellett azt is szeretnénk, ha a rugalmasság csúcsaként futásidőben is 
módosíthatnánk a program megjelenését. 


Az objektum-létrehozás elvonatkoztatása 

Minden, amit látunk, és amivel kapcsolatba kerülünk a Lexi felhasználói felületén, egy kép- 
jel, amely más, láthatatlan képjelekbe (Sor, Hasáb stb.) ágyazódik. A láthatatlan képjelek 
láthatókat állítanak elő (Gomb, Karakter stb.), és megfelelően elrendezik azokat. A külön- 
böző megjelenítési stílusok útmutatói részletesebben is leírják a felület ezen vezérlő eleme- 
inek ( widget") — gombok, gördítősávok, menük — kinézetét. A vezérlők egyszerűbb képje- 
lek, például karakterek, körök, négyszögek és sokszögek alapján építhetik fel magukat. 


Tételezzük fel, hogy két vezérlőosztályunk van, amelyek a különböző megjelenítési szab- 
ványok támogatására hivatottak: 


1. Elvont Képjel alosztályok halmaza minden vezérlőelem-kategóriához. Például egy 
elvont GördítőSáv (ScrollBar) osztállyal a képjel alapfelületét gördítőműveletekkel 
bővíthetjük ki, egy Gomb (Button) osztállyal gombműveleteket adhatunk hozzá és 
így tovább. 

2. Konkrét alosztályok halmaza minden elvont alosztályhoz, amelyek megvalósítják a kü- 
lönböző megjelenítési szabványokat. A ScrollBar-nak például lehetnek MotifScrollBar 
és PMScrollBar alosztályai, amelyek Motif és PM (Presentation Manager) stílusú gördí- 
tősávokat hoznak létre. 


A Lexinek meg kell tudnia különböztetni az egyes megjelenítési stílusokhoz kapcsolódó 
vezérlőket, például ha egy gombot kell kirajzolnia a program felületére, tudnia kell, melyik 
gombváltozat osztályát kell példányosítania (MotifButton, PMButton, MacButton stb.). 


Világos, hogy a Lexi megvalósítása ezt nem tudja közvetlenül, például C---ban egy 
konstruktorhívással megtenni. Ez a gombstílus kódban való rögzítését vonná maga után, így 
futásidőben nem választhatnánk stílust, ráadásul ha a programot másik rendszerre szeret- 
nénk átültetni, az összes ilyen konstruktorhívást meg kellene keresnünk és meg kellene vál- 
toztatnunk. És a gombok csupán a vezérlők egyik fajtáját jelentik a Lexi felhasználói felüle- 
tén... Az adott megjelenítési módhoz kapcsolódó osztályok konstruktorhívásainak elszórása 
a kódban a karbantartók rémálma — ha csak egy felett is átsiklik a tekintetünk, ott találhatjuk 
magunkat egy Mac programban, aminek a közepén egy Motif stílusú menü éktelenkedik. 





A Lexinek meg kell határoznia a megcélzott megjelenítési stílust, hogy létrehozhassa a meg- 
felelő vezérlőelemet. Nem csak a kifejezett konstruktorhívásokat kell elkerülnünk, hanem 
azt is biztosítanunk kell, hogy képesek legyünk könnyedén egy egész vezérlőkészletet le- 
cserélni. Mindkettő elérhető, ha az objektum-létrehozás folyamatát elvonttá tesszük. Egy 
példával mindjárt meg is világítjuk, mire gondolunk. 
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Gyárak és termékosztályok 


Normális esetben a következő C-t kóddal hozhatunk létre egy Motif stílusú gördítősáv- 
példányt: 


ScrollBart sb - new MotifScrollBar; 


Ezt a fajta kódot kell elkerülnünk, ha a Lexi megjelenítési szabványoktól való függőségét 
a lehető legkisebbre szeretnénk szorítani. De tegyük fel, hogy az sb gördítősávot az alábbi- 
ak szerint hozzuk létre: 


ScrollBary sb - guiFactory--cCreateScrollBatr ( ) ; 


Itt a guiFactory a MotifFactory (MotifGyár) osztály egy példánya. A CreateScrollBar 
(LétrehozGördítőSáv) a megfelelő ScrollBar alosztály egy pédányát adja vissza, a kívánt meg- 
jelenítési stílusnak, ebben az esetben a Motifnak megfelelően. Ami a felhasználó programokat 
illeti, a fenti kód hatása megegyezik azzal, mintha közvetlenül a MotifScrollBar konstruktort 
hívnánk meg — de van egy lényeges különbség: a kódban immár nem utal semmi név szerint 
a Motif stílusra. A guiFactory objektum nem csak a Motif gördítősávok létrehoz: ak fo- 
lyamatát teszi elvonttá, hanem bármely megjelenítési stílusnak megfelelő gördítősávét. Emel- 
lett a guiFactory nem szorítkozik a gördítősávok előállítására; vezérlők széles körét képes 
elkészíteni, így gombokat, beviteli mezőket, menüket és más vezérlőket is. 





Mindez azért lehetséges, mert a MotifFactory a GUlFactory (GUIGyár) alosztálya, ami a ve- 
zérlőelemek létrehozására szolgáló általános felületet meghatározó elvont osztály. Olyan 
műveleteket tartalmaz, mint a CreateScrollBar vagy a CreateButton (Létrehoz- 
Gomb), amelyek különféle vezérlőelemeket példányosítanak. A GUlFactory alosztályai 
ezen műveletek megvalósításával olyan képjeleket adnak vissza, mint a MotifScrollBar vagy 
a PMButton, amelyek egy bizonyos megjelenítési stílust képviselnek. A 2.9 ábra a GUT- 
Factory objektumok osztályhierarchiáját mutatja. 


Azt mondjuk, hogy ezek a gyárak" termék (product, produktum) objektumokat állítanak 
elő. Az egy adott gyár által létrehozott termékek rokonságban állnak egymással; esetünk- 
ben minden termék egy adott megjelenítési stílushoz igazodó vezérlő. A gyárak számára 
a vezérlők működtetéséhez szükséges termékosztályok egy részét a 2.10 ábra mutatja. 


Az utolsó kérdés, amit meg kell válaszolnunk, hogy honnan származik a GUlFactory pél- 
dány? A válasz pedig az, hogy bárhonnan, ha számunkra kényelmes. A guiFactory válto- 
zó lehet általános (globális), lehet egy jól ismert osztály statikus tagja, de lehet helyi változó 
is, amennyiben a teljes felhasználói felületet egyetlen osztályon vagy függvényen belül 
hozzuk létre. Az ilyen objektumok kezelésére létezik egy tervezési minta is, az Egyke 
(Singleton). A lényeg az, hogy a guiFactory bevezetésére a program azon pontján van 
szükség, amikor még nem kell vezérlőelemeket létrehoznunk vele, de már döntés születe- 
tett a használni kívánt megjelenítési szabványról. 


Programtervezési minták 





Ha a megjelenítési stílust fordításkor ismerjük, a guiFactory létrehozását a program ele- 
jén, egyszerűen egy új gyárpéldányt hozzárendelve elintézhetjük: 


GUIFactoryt guiFactory - new MotifFactory; 


Ha a felhasználó adhatja meg a program indításakor a megjelenítési stílust — mondjuk egy 
karakterlánc beírásával —, a gyárat létrehozó kód a következő lehet: 


GUIFactoryt guiFactory; 
const char" styleName - getenv( "LOOK AND FEEL"); 
// indításkor adja meg a környezet vagy a felhasználó 


if (strcmp(styleName, "Motif") -- 0) ( 
guiFactory - new MotifFactory; 


l else if(strcmp(styleName, "Presentation Manager") -- 0) ( 
guiFactory - new PMFactory; 






















) else ( 
guiFactory - new DefaultGUIFactory; 

) 
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2.9 ábra 
A GulFactory osztályhierarchiája. 
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2.10 ábra 


Elvont termékosztályok és konkrét alosztályok. 


Ennél persze vannak kifinomultabb módszerek is arra, hogy futásidőben kiválasszuk a meg- 
felelő gyárat. Készíthetünk például egy bejegyzés-adatbázist, amely karakterláncokat rendel 
az egyes gyárobjektumokhoz. Így anélkül jegyezhetünk be új gyár alosztályokat, hogy 
a meglevő kódot módosítanunk kellene, amit az előző megközelítés megkövetel — ráadásul 
nem kell minden rendszerfüggő gyárat belefordítanunk az alkalmazásba. Ez igen fontos, hi- 
szen a MotifFactory-t egy, a Motifot nem támogató rendszeren esetleg nem is kapcsolhatjuk 
a programhoz. 


A lényeg azonban az, hogy ha egyszer beállítottuk az alkalmazást a megfelelő gyár objek- 
tum használatára, azzal meghatároztuk a megjelenítési stílusát. Ha meggondoljuk magun- 
kat, újratölthetjük a guiFactory-t egy más megjelenítést támogató gyárral és újraépíthet- 
jük a felületet. Nem számít, mikor és hogyan döntünk e kérdésben, tudni fogjuk, hogy 
a döntés után a program képes lesz beállítani saját magát, anélkül, hogy bármit is módosíta- 
nunk kellene. 


Az Elvont gyár tervezési minta 

A gyárak és termékek az Elvont gyár minta kulcsfontosságú elemei. Ez a minta arra nyújt 
megoldást, hogyan hozhatjuk létre rokonságban álló termékobjektumok családját anélkül, 
hogy az osztályokat közvetlenül példányosítanunk kellene. A módszer használata akkor 
a legcélszerűbb, ha a termékobjektumok száma és típusa állandó, az egyes termékcsaládok 
között pedig különbségek vannak. A családok közül úgy választunk ki egyet, hogy egy 
konkrét gyárat példányosítunk, és következetesen azzal hozzuk létre a termékeket. Ha az 
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adott gyárat egy másik egy példányával váltjuk fel, egész termékcsaládokat cserélhetünk ki. 
Az Elvont gyárat az különbözteti meg a többi, egyetlen típusú termékobjektumot használó 
alkotó létrehozási mintától, hogy a hangsúlyt a termékek családjára helyezi, 


2.6 Több ablakkezelő rendszer támogatása 


A megjelenítési stílus csak egyike a hordozhatóság szempontjainak. A másik az ablakkeze- 
lő rendszer nyújtotta környezet, amelyben a Lexi fut. Az ablakkezelő rendszer adja azt az il- 
lúziót, hogy egy háttérképpel ellátott asztalon egymásra pakolt ablakokat látunk, ez hatá- 
rozza meg, hogy az ablakok mekkora és milyen képernyőterületet foglalhatnak el, és ez 
irányítja hozzájuk a billentyű- és egérüzeneteket. Számos elterjedt és egymással nagyrészt 
összeegyeztethetetlen ablakkezelő rendszer létezik (Macintosh, Presentation Manager, 
Windows, X stb.), mi pedig — ugyanabból az okból kifolyólag, amiért a különböző megjele- 
nítési stílusokat is támogattuk —azt szeretnénk, ha a Lexi a lehető legtöbbjükön futna. 


Használhatunk elvont gyárat? 

Első pillantásra úgy tűnik, itt egy újabb lehetőség az Elvont gyár minta használatára. 
Csakhogy az ablakkezelő rendszer hordozhatóságára vonatkozó megszorítások jelentő- 
sen különböznek azoktól a követelményektől, amelyek a megjelenítési stílus független- 
ségét biztosítják. 


Az Elvont gyár alkalmazásánál feltételeztük, hogy minden megjelenítési szabványhoz meg- 
határozunk egy konkrét vezérlőosztályt, ami azt jelentette, hogy egy elvont termékosztály- 
ból (amilyen pl. a ScrollBar) adott megjelenítési stílusnak megfelelő konkrét termékeket 
(MotifScrollBar, MacScrollBar stb.) származtathattunk. Ebben az esetben azonban azzal a fel- 
tevéssel kell élnünk, hogy különböző gyártóktól számos osztályhierarchiával rendelkezünk, 
amelyek egy-egy megjelenítési szabványt támogatnak, és nagy valószínűséggel egymással 
egyáltalán nem összeegyeztethetők. Így aztán nem lesz egy közös elvont termékosztályunk 
a különböző vezérlőkhöz (ScrollBar, Button, Menu stb.), e létfontosságú osztály nélkül pe- 
dig az Elvont gyár nem működik. Először meg kell oldanunk, hogy a különböző vezérlőhie- 
rarchiák képesek legyenek igazodni elvont termékfelületek egy közös halmazához, csak ez- 
után vezethetjük be megfelelően a Create . . . műveleteket elvont gyárunk felületében. 


A vezérlők esetében a fenti problémát úgy oldottuk meg, hogy megalkottuk saját elvont és 
konkrét termékosztályainkat. Most, amikor a Lexit megpróbáljuk képessé tenni arra, hogy 
több különböző ablakkezelő rendszeren is működőképes legyen, hasonló problémával ke- 
rülünk szembe, mégpedig azzal, hogy e rendszerek össze nem egyeztethető programozási 
felületekkel rendelkeznek. Ez egy kicsit keményebb dió, mint az előző, hiszen nem enged- 
hetjük meg magunknak, hogy Saját, nem szabványos ablakrendszert fejlesszünk ki. 


Szerencsére van megoldás. Akárcsak a megjelenítési szabványok, az ablakkezelő rendsze- 
rek felületei sem különböznek gyökeresen egymástól, hiszen lényegében ugyanazokat 
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a feladatokat hajtják végre. Tehát az ablakkezelő rendszer fogalmainak egységes halmazára 
lesz szükségünk, így a különböző megvalósításokat egyetlen közös felületbe tuszkolhatjuk. 


A megvalósítási függőségek egységbe zárása 

A 2.2 részben a képjelek, illetve képjelszerkezetek képernyőn való megjelenítésére beve- 
zettük a Window (Ablak) osztályt. Nem határoztuk meg az ablakkezelő rendszert, amellyel 
működik, hiszen ilyen kimondottan nem is volt. A Window osztály zárja egységbe azokat 
a dolgokat, amelyért az ablakok egy ablakrendszerben általában felelnek: 


e  Műveleteket biztosítanak az alapvető geometriai alakzatok rajzolásához. 
e  Lekicsinyíthetik és felnagyíthatják magukat. 





Felelősségi kör Műveletek 


virtual void Redraw() 
virtual void Raise() 
Ablákkézelés virtual void Lower() 
virtual void Iconify() 
virtual void Deiconify() 








virtual void DrawLinet( . . . ) 
virtual void DrawRect(...) 
Grafika virtual void DrawPolygon(...) 
virtual void DrawText(...) 














2.3 táblázat 
A Window osztály felülete. 


s Átméretezhetik magukat. 

e Tartalmukat igény szerint újrarajzolhatják, például amikor kis méretről visszaállítják 
őket eredeti méretükre, amikor egymással fedésbe kerülnek, vagy amikor addig elfe- 
dett területük a képernyő előterébe kerül. 


A Window osztálynak le kell fednie a különböző ablakrendszerek szolgáltatásainak teljes 
körét. Lássunk két szélsőséges megközelítést: 


1. A szolgáltatások metszete. A Window osztály felülete csak azokat a szolgáltatásokat 
tartalmazza, amelyek minden ablakrendszerben megtalálhatók. Ezzel a megközelí- 
téssel az a gond, hogy Window felületünk csak annyit fog tudni, amennyit a legkeve- 
sebb szolgáltatást nyújtó rendszer, így nem aknázhatjuk majd ki a fejlettebb képessé- 
geket, még ha a legtöbb (de nem az összes) ablakkezelő rendszer támogatja is azokat. 

2. A szolgáltatások uniója. Létrehozunk egy felületet, amelyben helyet kap minden lé- 
tező rendszer minden képessége. A gond itt az, hogy az eredményként előálló felü- 
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let hatalmassá és következetlenné válhat, ráadásul minden alkalommal módosíta- 
nunk kell (és vele a Lexit is, amely rá támaszkodik), ha akár csak egyetlen fejlesztő- 
cég is átalakítja ablakkezelő rendszerének felületét, 


Egyik szélsőséges megoldás sem kivitelezhető, így az arany középutat igyekszünk megta- 
lálni. Window osztályunk kezelhető felülettel fog rendelkezni, és a legtöbb népszerű szol- 
gáltatást támogatja majd. Miután a Lexi közvetlenül használja ezt az osztályt, a Window-nak 
támogatnia kell azokat az elemeket is, amelyeket a Lexi ismer, vagyis a képjeleket. Ez azt je- 
lenti, hogy a Window felületének alapvető grafikai műveleteket is tartalmaznia kell, ame- 
lyek segítségével a képjelek kirajzolhatják magukat az ablakban. A 2.3 táblázat egy lehetsé- 
ges művelethalmazt mutat, amit a Window osztály felülete tartalmazhat. 


A Window elvont osztály. Konkrét alosztályai biztosítják a különféle ablakok támogatását: 
az alkalmazások ablakai, az ikonok, a figyelmeztető üzenetek mind ablakok, de viselkedé- 
sük némileg különböző. Ezeknek megfelelően olyan alosztályokat határozhatunk meg, 
mint az AlkalmazásAblak (ApplicationWindow), az IkonAblak (IconWindow) vagy a Pár- 
beszédAblak (DialogWindow). Az előállított osztályhierarchia a Lexihez hasonló alkalma- 
zásoknak egységes, elvont ablakműködést biztosít, amely nem függ egyetlen fejlesztőcég 
ablakkezelő rendszerétől sem. 
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Most, hogy meghatároztunk egy ablakfelületet a Lexi számára, amellyel működhet, hol ke- 
zeljük ténylegesen a rendszerfüggő ablakokat? Ha nem készítünk saját ablakkezelő rend- 
szert, elvont ablakainkat előbb-utóbb a célrendszer által biztosított fogalmak segítségével 
kell felépítenünk. Vagyis mi lesz a megvalósítással? 


Az egyik lehetőség, hogy minden rendszerre külön változatot készítünk a Window osztály- 
ból és alosztályaiból, és akkor választjuk ki a megfelelőt, amikor egy adott felületre lefordít- 


2. fejezet " Esettanulmány: szövegszerkesztő tervezése 





55 





juk a programot. Ez azonban komoly fejfájást okozhat, hiszen számos Window nevű, de 
más-más rendszerre megvalósított osztályt kell számon tartanunk. Azt is megtehetjük, hogy 
a Window hierarchiában levő minden osztályból megvalósításfüggő alosztályokat hozunk 
létre — de ez az osztályok számának hasonló robbanásához vezet, mint amiről a díszítés 
kapcsán már szót ejtettünk. Emellett mindkét módszernek van még egy hátulütője: egyik 
sem nyújt kellő rugalmasságot, ugyanis a program lefordítása után már nincs lehetőségünk 
módosítani az ablakrendszert, ráadásul emiatt több futtatható állományt kell fenntartanunk. 


Egyik lehetőség sem túl vonzó, de mi mást tehetünk? Nos, ugyanazt, amit a formázás és 
a díszítés esetében: a változó tényezőt egységbe kell zárnunk. Ez pedig ebben az esetben az 
ablakkezelő rendszer megvalósítása. Ha az ablakrendszer szolgáltatásait egy objektumba 
zárjuk, az objektum felületéhez igazodva készíthetjük el a Window osztályt és annak alosz- 
tályait. Ha pedig a felület minden kívánt ablakrendszert képes kiszolgálni, az említett osztá- 
lyok egyikét sem kell módosítanunk a rendszer támogatásához. Az ablakobjektumokat egy- 
szerűen úgy igazíthatjuk a kívánt rendszerhez, hogy átadjuk a megfelelő ablakrendszer- 
betokozó objektumot. Így az ablakok futásidőben is módosíthatók. 


Window és Windowilmp 

Létrehozunk tehát egy külön Windowlmp (AblakMegvalósítás) osztályhierarchiát, amelyben 
elrejtjük a különböző ablakkezelő rendszerek megvalósításait. A Windowlmp egy elvont 
osztály lesz azon objektumok számára, amelyek a rendszerfüggő kódokat tartalmazzák. 
Ahhoz, hogy a Lexi egy adott ablakrendszeren működhessen, az egyes ablakobjektumokat 
a Windowlmp megfelelő alosztályának egy példányával állítjuk be. Az alábbi diagram 
a Window és Windowlmp hierarchiák közötti kapcsolatot mutatja: 
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A megvalósításokat a Windowlmp osztályokba rejtve elkerülhetjük a Window osztályok 
rendszerfüggő kódokkal való ,beszennyezését", és a Window hierarchiát kis méreten és 
stabilan tarthatjuk, miközben a megvalósítási hierarchia bővítésével az új ablakkezelők tá- 
mogatása könnyen megoldható marad. 
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A Windowlmp alosztályai 


A Windowlmp alosztályai a kérelmeket ablakrendszer-függő műveletekké alakítják át. 
Ha visszaemlékszünk a 2.2 részben bemutatott példára, ott a téglalaprajzoló Rectang- 
le: : Draw műveletet a Window példányon a DrawRect művelet alapján határoztuk meg: 


void Rectangle::Draw (Windowt w) ( 
w-sDrawRect ( x0, yO, x1, y1); 
) 


A DrawRect alapértelmezett megvalósítása a Windowlmp által bevezetett elvont téglalap- 
rajzoló műveletet használja: 


void Window: :DrawRect ( 

Coord x0, Coord y0O, Coord x1, Coord y1 
; 0! 

-imp-sDeviceRect (x0, y0O, x1, y1); 
) 


A fenti kódban az imp a Window tagváltozója, és az annak beállítására használt Win- 
dowlmp-et tartalmazza, Az ablak-megvalósítást tehát azon Windowlmp alosztálypéldány 
határozza meg, amelyre az. imp mutat. Egy XWindowlmp (vagyis az X Window rendszer 
számára készített Windowlmp alosztály) esetében a DeviceRect megvalósítása például az 
alábbi alakot öltheti: 





void XWindowImp: :DeviceRect ( 
Coord x0, Coord y0O, Coord xi, Coord y1 
) ( 
int x - round(min(x0, x1)); 
int y - round(íminíyO, y1)); 
int w - round(min(x0 - x1)); 
int h - röund(miníy0 - y1)); 
XDrawRectangle( dpy, . winid, gc, x, Yy, w, h); 
) 


A DeviceRect meghatározása azért így fest, mert az XDrawRectangle (a téglalaprajzo- 
lásra használt X felület) a téglalapokat bal alsó sarkukkal, szélességükkel és magasságukkal 
határozza meg; a DeviceRect-nek a kapott adatokból ezeket kell kiszámolnia. Először 
megállapítja, melyik a bal alsó sarok — elvégre az (x0,y0) bármelyik lehet a négy sarok 
közül -, majd kiszámítja a szélességet és magasságot. 


A PMWindowlmp (a Windowlmp alosztálya a Presentation Manager számára) másképp ha- 
tározná meg a DeviceRect-et: 


void PMWindowlInp : :DeviceRect ( 
Coord x0, Coord y0, Coord x1, Coord y1 
$ € 
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Coord left - min(x0, x1); 
CSGrd right - max(kXk0, XII; 
Coord bottom - min(yO0, y1); 
Coord top - max(yO0, y1); 


PPOINTL point[4]; 


point[0].x z- left; point[(0].y - top; 

point[1].x - right;point[1].y - top; 

pöínt [2] x z fidghtipoint[2] .Y z böttömz 

point(3].x z- left; point[3].y - bottom; 

1£ 4 
(GpiBeginPath( hps, 14) -- false) II 
(GpiSetCurrentPosition( hps, §£point[3]) -- false) II! 
(GpiPolyLine( hps, 4L, point) -- GPI ERROR) II 
(GpiEndPath( hps) -- false) 

pú 
//hibajelentés 

) else ( 


GpiStrokePath( hps, 1L, OL); 
) 
) 


Miért különbözik ez ennyire az X változattól? Nos, az az oka, hogy az X-szel ellentétben 
a PM nem rendelkezik kifejezett téglalaprajzoló művelettel, csak egy általános felülettel, 
amit a többszakaszos alakzatok (úgynevezett görbék, path) vektorainak meghatározására, il- 
letve az általuk körbezárt terület határolására és kitöltésére használ. 


A PM DeviceRect-megvalósítása tehát meglehetősen különbözik az X-étől, de ez nem 
számít. A Windowlmp az ablakrendszer-felületek változatosságát lehet, hogy nagy, de kel- 
lően stabil felület mögé rejti, így a Window alosztályok írói az elvont ábrázolással foglal- 
kozhatnak és nem kell az ablakkezelő rendszer részleteivel törődniük, ráadásul az új rend- 
szerek támogatásának beépítése is lehetővé válik a Window osztályok módosítása nélkül. 


Az ablakok beállítása az ablak-megvalósítások segítségével 

Egy kulcsfontosságú kérdés, amelyet még nem érintettünk, hogyan állítunk be egy ablakot 
a megfelelő Windowlmp alosztállyal? Másképp fogalmazva: mikor kerül sor az imp kez- 
deti beállítására, és hogyan állapítjuk meg, hogy éppen melyik ablakkezelőt (és követke- 
zésképpen melyik Windowlmp alosztályD) kell használjuk? Az adott ablaknak valamilyen 
Windowlmp-re mindenképpen szüksége lesz, mielőtt bármit csinálhatna. 


Több lehetőségünk is van, de mi arra összpontosítunk, amelyik az Elvont gyár mintát alkal- 
mazza. Létrehozhatunk egy elvont gyár osztályt (WindowSystemFactory, AblakRendszer- 
Gyár), amely felületet biztosít a különféle rendszerfüggő megvalósítási objektumok létre- 
hozásához: 
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class WindowSystemFactory ( 
public: 
virtual WindowImpt CreateWindowImp() - 0; 
virtual ColorImpY CreateColorImp() - 
virtual FontImpt CreateFontImp() - 0; 





// Create... művelet minden ablak-erőforráshoz 
1; 


Ezután minden ablakkezelő rendszerhez meghatározhatunk egy konkrét gyárat: 


class PMWindowSystemFactory : public WindowSystemFactory ( 
virtual WindowImpt CreateWindowImp() 
( return new PMWindowImp; ) 
Pi séz 
b; 
class XWindowsystemFactory : public WindowgystemFactory ( 
virtual WindowImpr CreateWindowImp () 
( return new XWindowImp; ) 
Fősgz 
hé 


A Window alaposztály konstruktora a WindowgystemFactory felület segítségével adhat kez- 
dőértéket (a használatban levő ablakkezelőnek megfelelő Windowlmp-et) az. imp tagnak: 


Window: :Window () ( 
-imp - windowgystemFactory-sCreateWindowImp ( ) ; 


) 


A windowSystemFactory változó egy WindowSystemFactory alosztály jól ismert példá- 
nya, amely hasonló a megjelenítési stílust meghatározó guiFactory változóhoz. A win- 
dowgystemFactory-nek ugyanazzal a módszerrel adhatunk kezdőértéket. 


A Híd tervezési minta 

A Windowlmp osztály az ablakrendszer szolgáltatásainak közös felületét határozza meg, de 
felépítését más megszorítások kötik, mint amik a Window felületére vonatkoznak. Az alkal- 
mazásprogramozók nem nyúlnak közvetlenül a Windowlmp felületéhez, csak a Window 
objektumokat kezelik. Így a Windowlmp felületének nem kell igazodnia az alkalmazás- 
programozó nézőpontjához, ami a Window osztályhierarchia és felület megtervezésénél 
szempont volt. A Windowlmp felülete közelebbről tükrözheti az ablakkezelő rendszer 
nyújtotta szolgáltatásokat, és a metszet, illetve unió megközelítés felé tetszőlegesen tolód- 
hat, attól függően, melyik illeszkedik jobban a célrendszerekhez. 


A lényeg az, hogy megértsük, a Window felület az alkalmazásprogramozó, míg a Window- 
Imp az ablakkezelő rendszer igényeit elégíti ki. Az, hogy a szolgáltatásokat két hierarchiá- 
ba rendezzük, lehetővé teszi, hogy a két felületet egymástól függetlenül valósíthassuk 
meg, a Lexi több rendszeren való működését pedig a két hierarchia objektumainak együtt- 
működése biztosítja. 
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A Window és a Windowlmp közötti kapcsolat a Híd tervezési mintára ad példát. A Híd mö- 
gött megbúvó szándék az, hogy lehetővé tegyük önálló, egymástól függetlenül fejleszthető 
osztályhierarchiák együttműködését. Tervezési céljaink ahhoz vezettek, hogy létrehoztunk 
két ilyen osztályhierarchiát, amelyek közül az egyik az ablakok logikai fogalmát, a másik 
pedig különböző megvalósításaikat támogatta. A Híd minta alkalmazásával az elvont logi- 
kai ablakokat úgy fejleszthetjük tovább, hogy nem kell az ablakrendszer-függő kódhoz 
hozzányúlnunk, és ez fordítva is igaz. 


2.7 Felhasználói műveletek 


A Lexi szolgáltatásainak egy része a dokumentum vizuális megjelenítésén keresztül érhető 
el: szöveget írunk be és törlünk, arrébb visszük a beszúrási pontot, az egérrel szövegrészle- 
teket jelölünk ki. Más szolgáltatásokat közvetve, a Lexi menüin, gombjain és gyorsbillen- 
tyűin keresztül használunk. Az ezek mögötti műveletek közé a következők tartoznak: 


s Új dokumentum létrehozása 

e Létező dokumentum megnyitása, mentés és kinyomtatása 

s Kijelölt szöveg kivágása a dokumentumból, illetve beillesztése a dokumentum más 
részére 

e Kijelölt szöveg stílusának és betűtípusának módosítása 

e A szövegformázás - igazítás, sorkizárt elrendezés — módosítása 

e Kilépés a programból 

s Egyéb műveletek 


E műveleteket a Lexi különböző felületeken teszi elérhetővé a felhasználó számára, de 
egyetlen művelet sem kötődik egyetlen felülethez. Célunk az, hogy a műveletek többféle 
módon is végrehajthatók legyenek, például egy másik oldalra átugorhassunk egy gomb, de 
akár egy menüpont segítségével is. Az is elképzelhető, hogy a jövőben változtatni szeret- 
nénk a felhasználói felületen. 


A műveleteket emellett több különböző osztályban valósítjuk meg. Fejlesztőként anélkül 
szeretnénk elérni őket, hogy a felhasználói felületi és megvalósító osztályok között túl sok 
függőséget alakítanánk ki, mert a túl szorosan csatolt megvalósítás kevésbé átlátható és 
karbantartható, illetve nehezebben bővíthető. 


Tovább bonyolítja a dolgokat, hogy azt szeretnénk, ha a Lexi támogatná néhány, de nem 
minden művelet visszavonását és megismétlését". Egészen pontosan az olyan dokumen- 
tum-módosító műveletek visszavonására szeretnénk lehetőséget, mint a törlés, amivel a fel- 
használó szándékán kívül rengeteg adatot törölhet véletlenül, de nem kívánunk visszavon- 
ni olyan műveleteket, mint egy rajz mentése vagy a programból való kilépés. E műveletek- 
nek függetleneknek kell lenniük a visszavonási folyamattól. Emellett korlátozni sem kíván- 
juk a visszavonások számát. 








" Vagyis egy éppen visszavont művelet újbóli végrehajtását. 
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Nyilvánvaló, hogy a felhasználói műveletek támogatása az egész alkalmazást át meg átszö- 
vi. A kihívást az jelenti, hogy olyan megoldással kell előrukkolnunk, ami az igények kielé- 
gítése mellett egyszerű és könnyen bővíthető. 


Kérelem egységbe zárása 

Tervezői szempontból a lenyitható menü is csak egy képjel, ami további képjeleket tartal- 
maz. Az különbözteti meg más, gyermekekkel rendelkező képjelektől, hogy a benne levők 
kattintásra valamilyen műveletet hajtanak végre. 


Tegyük fel, hogy ezek a műveletvégző képjelek a Glyph Menultem (MenüElem) alosztályá- 
nak példányai, és működésüket egy ügyféltől? érkező kérelem váltja ki. A kérelem teljesíté- 
se járhat egyetlen objektumon végzett művelettel, több objektumon végzett több művelet- 
tel, vagy lehet valahol a kettő között. 


Megtehetnénk, hogy minden felhasználói művelethez létrehozzuk a Menultem egy alosztá- 
lyát, majd ezekbe , bedrótozzuk" a kérelem végrehajtását biztosító kódot, de ez nem igazán jó 
megközelítés; semmivel sincs jobban szükségünk minden kérelemhez külön alosztályra, mint 
külön osztályokra egy lenyíló menü minden eleméhez. Ráadásul így a kérelmet egy adott fel- 
használói felülethez kötnénk, ami megnehezítené, hogy más módon is teljesíthessük a kérést. 


Példaként tegyük fel, hogy a dokumentum utolsó oldalára szeretnénk ugrani, és erre kétfé- 
le módszert szeretnénk. Az egyik, hogy egy menüben megjelenő Menultem-re kattintunk, 
a másik pedig, hogy a Lexi ablakának alján levő oldalikonra (ami rövidebb dokumentu- 
moknál jóval kényelmesebb lehet). Ha a kérelmet öröklés útján a Menultem-hez kapcsol- 
juk, akkor ugyanezt kell tennünk az oldalikon esetében is, sőt minden olyan vezérlő eseté- 
ben, amellyel esetleg ugyanezt a műveletet kívánjuk végrehajtani. Ezzel az osztályok száma 
ugrásszerűen megnőhet, akár a vezérlőtípusok és kérelemtípusok számának szorzatáig. 


Amivel nem rendelkezünk, az egy megoldás, amellyel a menüelemeknek paramétereket ad- 
hatnánk át, amelyekben megkapják a végrehajtandó kérelmet. Ezzel elkerülhetnénk az osztá- 
lyok számának növelését, és nagyobb futásidejű rugalmasságot érhetnénk el. A Menultem 
például kaphatna paraméterként egy függvényt, amit meghívhat, de ez három okból nem 
nyújtana tökéletes megoldást: 


1. Nem oldhatnánk meg a visszavonás-ismétlés problémáját. 

2. Állapotot függvénnyel összekapcsolni nehéz. Például egy függvénynek, ami megvál- 
toztatja a betűtípust, tudnia kell, melyik betűtípus van érvényben. 

3. A függvények nehezen bővíthetők, és részleteikben nehezen újrahasznosíthatók. 


A fentiek azt sugallják, hogy a menüelemeknek nem függvényt, hanem objektumot kellene 
paraméterként átadnunk. Ezután már használhatunk öröklést a kérelem megvalósításának 
bővítéséhez, illetve újrahasznosításához, lesz helyünk, ahol tárolhatjuk az állapotot, és 





" Elvben az ügyfél a Lexi felhasználója, valójában azonban egy másik objektum (például egy eseménytovábbító), 
amely a felhasználói bemeneteket kezeli. 
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megvalósíthatjuk a visszavonást, illetve ismétlést biztosító műveleteket. Íme egy újabb pél- 
da a változó elem egységbe zárására, ami ebben az esetben egy kérelem. A kérelmeket 
egy-egy parancs objektumba zárjuk. 


A Command osztály és alosztályai 

Először is, létrehozzuk a Command (Parancs) elvont osztályt, ami a kérelmek kiadásához 
biztosítja a felületet. Az alapfelület egyetlen elvont műveletből áll, amelyet Execute-nak 
(Végrehaj0)) nevezünk. A Command alosztályai a különböző kérelmek végrehajtásához kü- 
lönféle módokon valósítják meg az Execute műveletet. Egyes alosztályok munkájuk egy ré- 
szét vagy egészét más objektumra ruházhatják át, mások képesek önmaguk kielégíteni 
a kérelmet (lásd a 2.11 ábrát). A kérelmező ugyanakkor nem lát különbséget a Command 
(Parancs) objektumok között, mindet egyformán kezeli. 


A Menultem tárolhatja a Command objektumot, ami a kérelmet egységbe zárja (2.12 ábra). 
Minden menüelem objektumnak a megfelelő Command alosztály egy példányát adjuk át, 
illetve meghatározzuk a szöveget, ami a menüelem helyén megjelenik. Amikor a felhaszná- 
ló kiválaszt egy menüpontot, a Menultem egyszerűen meghívja az Execute műveletet az ál- 
tala tárolt Command objektumra, így teljesíti a kérelmet. A gombok és más vezérlők ugyan- 
úgy használhatják a parancsokat, mint a menüelemek. 
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A Command osztályhierarchia részlete. 
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2.12 ábra 
A Menultem és a Command kapcsolata. 


Visszavonási lehetőség 

A visszavonás, illetve újbóli végrehajtás lehetősége igen fontos az interaktív alkalmazások- 
ban. E parancsok végrehajtását a Command felülethez adott Unexecute (Ismét vagy Mégse) 
művelettel biztosítjuk, Az Unexecute megfordítja a megelőző Execute művelet hatását, még- 
pedig annak az információnak a felhasználásával, amelyet az Execute tárol. A Font- 
Command (BetűtípusParancs) esetében például az Execute a betűtípusváltás által érintett 
szövegrészt, illetve az eredeti betűtípust raktározza el, így az adott szövegrészletet az 
Unexecute visszaállíthatja korábbi állapotába. 


A visszavonás lehetőségéről néha futás közben kell dönteni. A kijelölt szöveg betűtípusá- 
nak megváltoztatására irányuló kérelem például nem eredményez semmit, ha a szöveg már 
eredetileg is az új betűtípussal íródott. Tegyük fel, hogy a felhasználó kijelöl egy részt, és ki- 
ad egy ilyen felesleges parancsot. Mi legyen a hatása az ezután kiadott Visszavonás pa- 
rancsnak? Járjon egy értelmetlen változtatás egy ugyanolyan értelmetlen művelettel? Termé- 
szetesen nem. Ha a felhasználó néhányszor megismétli a felesleges betűtípusváltási paran- 
csot, nem szabad, hogy ugyanannyi visszavonási műveletre legyen szükség ahhoz, hogy 
visszajussunk az utolsó értelmes műveletig. Ha egy parancs végrehajtása semmilyen válto- 
zást nem eredményez, egyáltalán nincs szükség visszavonási műveletre. 


Így aztán ahhoz, hogy meghatározhassuk, hogy egy művelet visszavonható-e, a Command 
felülethez hozzáadjuk az elvont Reversible (Megfordítható) műveletet, amely egy logikai 
(Bool-féle) értéket ad vissza. Az alosztályok e művelet felülírásával adhatnak vissza igaz 
vagy hamis (true-false) értéket futásidőben. 
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Parancselőzmények 


A visszavonás-újbóli végrehajtás tetszőleges szintjének támogatásához az utolsó lépés a pa- 
rancselőzmények listájának meghatározása, vagyis azon műveleteknek, amelyeket végrehaj- 
tottunk vagy visszavontunk. Elméletben a parancselőzmények listája valahogy így fest: 


-—— régebbi parancsok 


jelen 


Mindegyik kör egy-egy Parancs (Command) objektumot jelképez. Ebben az esetben a fel- 
használó négy parancsot adott ki: a bal szélsőt először, a másodikat másodszor, és így to- 
vább, míg a jobb szélső, vagyis az utoljára kiadott parancshoz nem érünk. A , jelen" felirattal 
ellátott vonal jelöli a legutolsó végrehajtott (vagy visszavont) parancsot. 


Az utolsó parancs visszavonásához egyszerűen meghívjuk az Unexecute műveletet az utol- 
só parancsra: 


Unexecute() 
jelen 


A visszavonás után a , jelen" vonalát eggyel balra toljuk. Ha a felhasználó úgy dönt, hogy még 
egy műveletet visszavon, a balra következő parancsra kerül sor, és az alábbi helyzet áll elő: 





jelen 


Látható, hogy ezen eljárás egyszerű ismétlésével többszintű visszavonásra nyílik lehetőség; 
a szintek számát csupán a parancselőzmények listájának hossza korlátozza. 


Programtervezési minták 





Egy éppen visszavont parancs újbóli végrehajtásához ugyanezt az eljárást követjük, csak 
megfordítva. A jelen vonalától jobbra levő parancsok azok, amelyek visszavonása vissza- 
vonható. Az utoljára visszavont parancs újbóli végrehajtása úgy történik, hogy a jelen vona- 
lától jobbra levő első parancsra meghívjuk az Execute műveletet: 


gepe () 


jelen 


Ezután a jelen vonalát jobbra visszük, hogy a legközelebbi Ismét művelet a következő 
visszavont művelet hatását álíthassa vissza: 


-———— múlt jövő — 
jelen 


Természetesen ha a következő művelet nem egy újabb Ismét, hanem Visszavonás, a jelen 
vonalától balra levő első parancsot fogjuk visszavonni, Így a felhasználó tetszőlegesen mo- 
zoghat a parancsok között, ha meggondolná magát vagy ki szeretne javítani egy hibát. 


A Parancs tervezési minta 

A Lexi parancsai a Parancs (Command) tervezési minta alkalmazását tükrözik, ami azt írja 
le, hogy zárhatunk egységbe egy kérelmet. A minta a kérelmek kiadásához egységes felüle- 
tet követel meg, amely lehetővé teszi, hogy az ügyfelek különböző kérelmeket fogadhassa- 
nak, hiszen a felület elszigeteli őket a kérelem megvalósításától. A kérelem végrehajtását 
a parancs végezheti teljes egészében maga, de részben vagy egészben át is ruházhatja 
a megvalósítást más objektumokra. Ez a Lexihez hasonló alkalmazások számára tökéletes, 
mert Így a program különböző részein elszórt szolgáltatásokhoz központi elérést biztosít- 
hatunk. A minta a Command alapfelületre építve megoldást nyújt a visszavonás és újbóli 
végrehajtás problémájára is. 
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2.8 Helyesírás-ellenőrzés és elválasztás 


Az utolsó bemutatandó tervezési probléma a szöveg elemzését igényli, mégpedig a helytele- 
nül írt szavak megkeresését és a szebb formázás érdekében elválasztási pontok beszúrását. 


Az elvárások itt hasonlók, mint a 2.3 részben bemutatott formázási probléma megoldásá- 
nál. Ahogy a sortörési módszerekből is több lehetett, a helyesírás ellenőrzése és az elválasz- 
tási pontok meghatározása is többféleképpen történhet, vagyis több algoritmus támogatá- 
sára lesz szükség, így választhatunk majd, mi a fontosabb: a tárigény, a sebesség vagy 
a ,minőség". Emellett azt is el kell érnünk, hogy később könnyen adhassunk a programhoz 
új algoritmusokat. 


Az említett szolgáltatások merev bekódolása a dokumentumszerkezetbe kerülendő, még 
inkább, mint a formázás esetében, mert a helyesírás-ellenőrzés és elválasztás csupán kettő 
azon lehetséges elemző műveletek közül, melyek támogatását be szeretnénk építeni 
a Lexibe. Természetes, hogy idővel további ilyen irányú képességekkel szeretnénk bővíteni 
a programot, például keresési lehetőségekkel, a szavak megszámlálásával, számológéppel 
a táblázatos értékek beszúrásához, nyelvtani ellenőrzéssel és így tovább. A Glyph osztályt 
és alosztályait azonban nem szeretnénk minden alkalommal módosítani, amikor új szolgál- 
tatást adunk az alkalmazáshoz. 


A kirakósjátéknak tulajdonképpen két darabja van: (1) az elemzendő információ elérése, 
amely a dokumentumszerkezet képjeleiben szétszórva helyezkedik el, illetve (2) az elem- 
zés végrehajtása. E két feladattal külön foglalkozunk. 


Az elszórt információ elérése 

Számos elemzéstípusnál a szöveg karakterről karakterre való átvizsgálására van szükség, az 
elemzendő szöveg pedig képjel objektumok hierarchikus szerkezetében szétszórva helyez- 
kedik el. Egy ilyen felépítésű szöveg vizsgálata olyan elérési módszert igényel, amely ,is- 
meri" azokat az adatszerkezeteket, amelyekben az objektumok tárolódnak. Egyes képjelek 
gyermekeiket láncolt listában tárolhatják, mások tömböket alkalmazhatnak, megint mások 
pedig még különlegesebb adatszerkezeteket. Elérési módszerünknek mindegyik lehetősé- 
get támogatnia kell. 


Tovább bonyolítja a helyzetet, hogy a különböző elemző műveletek más-más módon érik 
el az adatokat. A legtöbb elemző művelet elejétől végéig járja be a szöveget, de néhány en- 
nek ellenkezőjét teszi — fordított keresést alkalmaz, például hátulról előre halad a szöveg- 
ben, Az algebrai kifejezések kiértékelése például sokszor úgynevezett balról jobbra haladó 


bejárást (inorder bejárás, bal részfa-gyökér-jobb részfa sorrend) igényel. 


Tehát az elérési módszernek több adatszerkezettel kell működnie, és a bejárás különböző 
típusait — előre haladó, visszafelé haladó, balról jobbra haladó — is támogatnunk kell. 
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Az elérés és bejárás egységbe zárása 


Pillanatnyilag képjelfelületünk egész sorszámokkal teszi lehetővé az ügyfeleknek, hogy 
a gyermekekre hivatkozzanak. Bár ez ésszerűnek tűnhet a gyermekeiket egy tömbben tá- 
roló képjelosztályoknál, azoknál nem túl hatékony, amelyek láncolt listát használnak erre. 
Az elvont képjel-ábrázolás egyik fontos feladata, hogy elrejtse, milyen adatszerkezeteket 
használ az adott osztály a gyermekek tárolására, hiszen így anélkül változtathatjuk meg az 
adatszerkezetet, hogy ez más osztályokat érintene. Ennélfogva csak a képjel tudja, milyen 
adatszerkezetet is használ. Nyilvánvaló, hogy felületének nem szabad egyik szerkezetet 
sem előnyben részesítenie a többivel szemben, tehát a jelenlegi helyzet, amikor is jobban 
illeszkedik a tömbökhöz, mint például a láncolt listákhoz, nem előnyös. 


E problémát és a bejárások különböző fajtáinak támogatását egyszerre oldhatjuk meg. Köz- 
vetlenül a képjelosztályokban elhelyezhetünk több elérési és bejárási módszert, és módot 
adhatunk az azok közötti választásra, mondjuk egy felsoroló típusú állandót paraméterként 
átadva. Az osztályok aztán ezt a paramétert továbbadhatják egymásnak, hogy biztosítsák, 
mindannyian ugyanazt a bejárási módszert has álják. Emellett tovább kell adniuk a bejá- 
rás közben megszerzett valamennyi információt is. A fenti megközelítést támogatandó 
következő elvont műveleteket adhatjuk a Glyph felületéhez: 





void First (Traversal kind) 
void Next () 

bool IsDone () 

Glyph" GetCurrent () 

void Insert(Glyph") 


A bejárást a First (Első), Next (Következő) és IsDone (Kész) műveletek vezérlik. A First 
indítja el, miután a felsoroló állandó típusú Traversal (Bejárás) paraméterben megkapja 
a bejárás módját (kind). A paraméter értéke CHILDREN, PREORDER, POSTORDER és 
INORDER lehet. Az első esetében csak a képjel közvetlen gyermekeit járjuk be, a másodiknál 
a teljes szerkezetet, előrefelé haladva. A Next a következő képjelre ugrik, az IsDone pedig 
jelentést ad, hogy a bejárás véget ért-e vagy sem. A Child (Gyermek) műveletet 
a GetCurrent (ElérAktuális) váltja fel, amely a bejárás során éppen érintett képjelet éri el. 
Az Insert (Beszúr) a korábbi, hasonló nevű műveletet cseréli le és beszúrja az adott képje- 
let az aktuális helyre. Az elemzés során a következő C--4 kódot használhatnánk egy g gyö- 
kerű képjelszerkezet előre haladó bejárásához: 


Glyph"t g; 








for (g-sFirst(PREORDER) ; !1g-sIsDone(); g-2Next()) ( 
Glypht current - g-5sGetCurrent ( ) ; 


// valamilyen elemzés 


bi 


Megfigyelhetjük, hogy az egész számokkal való sorszámozást kigyomláltuk a képjel felületé- 
ből, így az nem tolódik el többé egyik gyűjteménytípus támogatása felé sem. Attól is megkí- 
méltük az ügyfeleket, hogy maguknak kelljen megvalósítaniuk az általános bejárástípusokat. 
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A megközelítéssel azonban továbbra is vannak gondok. Először is, nem képes támogatni új 
bejárási módokat anélkül, hogy új értékekkel egészítenénk ki a felsoroló típust vagy új műve- 
leteket írnánk. Tegyük fel, hogy az előre haladó bejárás egy olyan változatát szeretnénk, ami 
automatikusan átugorja a nem szöveget jelölő képjeleket. Ekkor a Traversal felsorolást 
módosítanunk kellene, hogy tartalmazzon egy TEXTUAL PREORDER (SZÖVEGES ELŐRE) 
vagy hasonló értéket. 


A meglevő deklarációk megváltoztatását el szeretnénk kerülni. Ha a bejárási módszert teljes 
egészében a Glyph osztályhierarchiába helyezzük, módosításához vagy bővítéséhez való- 
színűleg számos osztályt meg kell változtatnunk, az is nehézzé válik, hogy más típusú ob- 
jektumszerkezetek bejárásához újrahasznosítsuk, ráadásul csak egy folyamatban levő bejá- 
rás lehetséges. 





Ismét csak jobb megoldás a változó tényező egységbe zárása, ez pedig ebben az esetben az 
elérési és bejárási módszer. Ezért bevezetjük a Bejáró (Iterator) objektumok osztályát, 
amelynek egyetlen feladata a különböző bejárási módszerek meghatározása. Öröklés segít- 
ségével egységesítjük a különböző adatszerkezetek elérését, és támogatjuk az új bejárási 
módszereket is. Így nem kell megváltoztatnunk a képjelfelületeket vagy a képjelek megva- 
lósításait terhelnünk ezzel a feladattal. 


 HMSZZSZZEZEOG ESÉSE TEL EZEK EEG zi Ess 


First) 

Next) 
IsDone() 
Currentltem() 
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[/ Preorderlterator Arrayiterator Listiterator Nulllterator ] 
bejárók 
First) First) First) First0) 
Next) Next) Next() Next) 
IsDone) d tsDone() IsDone() tisDone() 9-- jat 
Currentltem() Currentltem() Currentítem() Currentltem() jj 
, 
gyökér currentltem i 
return true 
———— pt Glyph 
Createlterator() 0-f------ return new Nulliterator 
2.13 ábra 


Az lterator osztály és alosztályai. 
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Az Iterator osztály és alosztályai 


Az elérés és bejárás közös felületét az Iterator (Bejáró) nevű elvont osztály határozza meg. 
A konkrét alosztályok közül az Arrayiterator (TömbBejáró) és a Listlterator (istaBejáró) e felület 
megvalósításával a tömbök és listák elérését biztosítják, míg a Preorderlterator, a Postorderlterator 
és hasonlók az egyes szerkezetek bejárását. Mindegyik Iterator alosztály egy hivatkozást tartal- 
maz arra a szerkezetre, amit bejár; példányaik létrehozásukkor ezt a hivatkozást kapják kezdő- 
értékül. A 2.13 ábra az Iterator osztályt és néhány alosztályát mutatja. Megfigyelhető rajta, hogy 
a bejárók támogatásához a Glyph osztályhoz adtunk egy Createlterator (LétrehozBejáró) nevű 
elvont műveletet. 


A bejárás vezérléséhez az Iterator felület a First, Next és IsDone műveleteket biztosítja. 
A Listlterator osztály First-megvalósítása a lista első elemére mutat, a Next a listában követke- 
ző elemre lép, az IsDone pedig azt adja vissza, hogy a listamutató az utolsó elemen túlra mu- 
tat-e. A Currentltem (AktuálisElem) a bejáró hivatkozásának követésével a hivatkozott képje- 
let adja vissza. Az Arraylterator osztály feladata hasonló, de képjelek tömbjére vonatkozik. 


A képjelszerkezet gyermekeit most már anélkül érhetjük el, hogy ismernénk a szerkezet áb- 
rázolását: 


Glyph" g; 
IteratorcGlyphtor i - g-sCreatelterator( ) ; 


for (i-sFirst(); !i-sIsDone(); i-sNext()) ( 
Glyph" child - i-sCurrentltem( ) ; 


// csinálunk valamit az aktuális gyermekkel 
) 


A Createlterator alapértelmezés szerint egy Nulllterator (NullBejáró) példányt ad vissza. 
A Nulllterator egy csökevényes bejáró a gyermekkel nem rendelkező képjelek, vagyis a le- 
vél képjelek számára. A Nulllterator ISDone művelete mindig igazat ad vissza. 


A gyermekkel rendelkező képjel-alosztályok felülbírálják a Createlteratort, így egy másik 
Iterator alosztály egy példányát adják vissza. Az, hogy melyiket, attól függ, milyen szerkezet 
tárolja a gyermekeket. Ha a Glyph Row alosztálya gyermekeit példáula children nevű 
listában tárolja, Createlterator művelete az alábbihoz hasonlóan fog festeni: 


IteratorcGlypht5Yy Row: :Createlterator () ( 
return new ListlteratorcGlypht5( children) ; 


is 


Az előre haladó és balról jobbra haladó (inorder) bejárások képjelfüggő bejárókkal dolgoz- 
nak. E bejárókat a bejárandó szerkezet gyökerében levő képjel adja meg. A bejárók meg- 
hívják a Createlteratort a szerkezetben levő képjelekre és az eredményként kapott bejáró- 
kat egy verem segítségével követik nyomon. 
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A Preorderlterator osztály például megszerzi a bejárót a gyökérképjeltől, beállítja, hogy az 
első elemére mutasson, majd a verem tetejére helyezi: 


void Preorderlterator::First () ( 
IteratorcGlyphtot i -  root-sCreatelterator ( ) ; 





át (ük 





sFirst(); 
-iterators.RemoveAl1 () ; 
-iterators.Push(i); 


A Currentltem egyszerűen meghívja a Currentltem-et a verem tetején levő bejáróra: 


Glyph" Preorderlterator: :Currentltem () const ( 
return 
iterators.Size() 50? 
iterators.Top()-sCurrentIltem() : 0; 
1 


A Next művelet veszi a verem tetején levő bejárót és első elemét egy bejáró létrehozására 
utasítja, hogy olyan messzire nyúlhasson a képjelszerkezetben, amennyire csak lehet (végül 
is előre haladó bejárásról van szó). A Next az új bejárót a bejárandó szerkezet első elemére 
állítja, majd a verem tetejére helyezi. Ezután a Next ellenőrzi a legutóbbi bejárót: ha IsDone 
művelete igazat ad vissza, az aktuális részfa (vagy levél) bejárását befejezettnek tekinthetjük. 
Ebben az esetben a Next leveszi a verem tetején levő bejárót és addig ismétli a folyamatot, 
amíg csak teljesen be nem járt szerkezeteket talál. Ha elfogytak, a bejárást befejeztük. 


void Preorderlterator::Next () ( 
IteratorcGlyphtsot i - 
.iterators.Top()-5sCurrentItem( ) sCreatelterator ( ) ; 


i-sFirst(); 
.-iterators.Push(i); 


while ( 
.iterators.Size() 5 0 §£ . iterators.Top()-5IsDone() 


delete . iterators.Pop() ; 
.-iterators.Top()-sNext(); 


) 


Figyeljük meg, hogy az Iterator osztályhierarchia hogyan teszi lehetővé, hogy új fajta be- 
járásokat adjunk meg, anélkül, hogy a képjelosztályokat módosítanunk kellene — egysze- 
rűen új Iterator alosztályokat hozunk létre, majd megadjuk az új bejárási módot, mint 


70 


Programtervezési minták 





a PreorderIterator-nél. A képjel-alosztályok ugyanazt a felületet használják, hogy az 
ügyfelek a gyermekeket a tárolásukra használt adatszerkezetek felfedése nélkül érhessék 
el. Miután a bejárók a bejárás állapotát maguk is tárolják, egyszerre több bejárást végez- 
hetünk, akár ugyanazon a szerkezeten. Emellett — bár a példában képjelszerkezeteket jár- 
tunk be - a PreorderIterator-hoz hasonló osztályoknak paraméterként átadhatjuk az 
objektumok típusát, így a kódot újrahasznosítva más szerkezeteket is bejárhatunk. 
A C44-ban erre sablonokat alkalmaznánk. 


A Bejáró tervezési minta 

A Bejáró (terator) minta az objektümszerkezetek elérését és bejárását támogatja. Nem csak 
összetett szerkezetek esetében alkalmazható, de gyűjteményekre is. Elvonatkoztatja a bejá- 
rási algoritmust és elrejti a bejárandó objektumok belső szerkezetét az ü gyfelek elől. Vagyis, 
a Bejáró minta ismét csak arra példa, hogyan érhetünk el nagyobb rugalmasságot és újra- 
hasznosíthatóságot a változó elem egységbe zárásával. A bejárás kérdésköre persze igen bo- 
nyolult, de a minta szerencsére az itt bemutatottnál sokkal több mindenre használható. 


Bejárás vagy bejáró műveletek? 
Most, hogy rendelkezünk egy módszerrel a képjelszerkezet bejárására, ellenőrizhetjük a he- 
lyesírást és az elválasztást. Mindkét elemzés információk gyűjtését igényli a bejárás közben. 


Először is el kell döntenünk, hová helyezzük az elemzésért felelős kódot. Tehetnénk példá- 
ul az Iterator osztályokba, így az elemzést a bejárás szerves részévé tennénk, Ennél azon- 
ban nagyobb rugalmasságot és újrahasznosíthatóságot érhetünk el, ha a bejárást és a bejá- 
rás közben végzett műveleteket elválasztjuk egymástól, már csak azért is, mert különböző 
elemző műveletek igényelhetik ugyanazt a fajta bejárást; ennélfogva ugyanazt a bejáróhal- 
mazt különféle elemzésekhez használhatjuk. Az előre haladó bejárás például számos elem- 
zés alapja: ilyen a helyesírás-ellenőrzés, az elválasztás, az előre haladó keresés vagy a sza- 
vak megszámlálása. 


Tehát az elemzés és a bejárás legyen egymástól független. De akkor kire ruházzuk az elem- 
zés felelősségét? Tudjuk, hogy többféle elemzést is végezni szeretnénk, melyek mindegyike 
a bejárás más-más pontján hajt végre műveleteket. Az elemzéstől függően egyes képjelek 
fontosabbak lehetnek másoknál. Ha a helyesírást ellenőrizzük vagy szavakat választunk el, 
a karakter képjeleket szeretnénk figyelembe venni, és nem a grafikusakat, amilyenek a so- 
rok vagy a bitképek. Ha szín alapján válogatunk, nyilván a látható képjelekre, és nem a lát- 
hatatlanokra lesz szükségünk. A különböző elemzések során tehát más-más képjeleket 
elemzünk. 


Egy adott elemzésnek nyilvánvalóan különbséget kell tudnia tenni a különböző képjel- 
típusok között. Így kézenfekvőnek látszik, hogy az elemző képességgel magukat 
a képjelosztályokat bővítsük. Mondjuk minden elemzéstípushoz egy vagy több elvont mű- 
veletet határozunk meg a Glyph osztályban, az alosztályok pedig ezeket az elemzésben ját- 
szott szerepüktől függően valósítják meg. 
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Ezzel a megközelítéssel azonban az a gond, hogy minden új elemzéstípus esetében módo- 
sítanunk kell az összes képjelosztályt. Egyes esetekben ezen enyhíthetünk: például ha az 
elemzésben csak kevés osztály vesz részt, vagy ha az elemzést a legtöbb osztály azonos 
módon végzi, az elvont művelet egy alapértelmezett megvalósítását megadhatjuk a Glyph 
osztályban. Ez lefedné az alapeseteket, és szükség esetén csak a Glyph osztályt kellene mó- 
dosítani, illetve azokat az alosztályokat, amelyek eltérnek az alapértelmezett viselkedéstől. 


De még ha az alapértelmezett megvalósítás csökkenti is a szükséges változtatások számát, 
marad egy gond: a Glyph felülete minden hozzáadott elemzési képességgel nő, ezek pedig 
idővel elfedik a Glyph alapfelületét, Nehéz lesz meghatározni, mi is a képjel eredeti célja: 
a megjeleníthető, alakkal rendelkező objektumok meghatározása és rendszerezése. A felü- 
let elveszik a ,zajban". 


Az elemzés egységbe zárása 

úgy tűnik tehát, az elemzést mégis csak külön objektumba kell zárnunk, ahogy eddig is tet- 
tük. Így egy adott elemzés kódja saját osztályba kerül, és ennek az osztálynak egy példá- 
nyát használjuk majd a megfelelő bejáróval, ami a példányt a szerkezet egyes képjeleihez 
, szállítja", ahol az elemző objektum a bejárás pontjain elvégzi a munkáját. A bejárás előre- 
haladtával az elemző információt gyűjt (ebben az esetben karakterekeD: 
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Az alapvető kérdés ezzel a megközelítéssel kapcsolatban az, hogyan különbözteti meg az 
elemző a különféle képjeleket anélkül, hogy típusellenőrzést vagy -átalakítást végezne. 
Az alábbihoz hasonló (ábkód megjelenését a spellingChecker (Helyesírás-ellenőrző) 
osztályban el szeretnénk kerülni: 


void SpellingChecker::Check (Glyphr glyph) ( 
Charactert c; 
Rowt r; 
Imaget i; 


if (c - dynamic castcCharactert5(glyph)) ( 
// a karakter elemzése 


) else if (r - dynamic castcRowt5(glyph)) ( 
// előkészület r gyermekeinek elemzésére 


) else if (i - dynamic castcImagets(glyph)) ( 
// semmit nem csinálunk 


) 


Ez meglehetősen csúnya kód, ami olyan kerülendő műveleteken alapul, mint a típusbiztos 
átalakítás (dynamic cast), ráadásul nehezen bővíthető és a Glyph osztályhierarchia módosí- 
tása esetén a fenti függvény törzsét is módosítanunk kell. Pontosan az a fajta kód, aminek 
elkerülésére az objektumközpontú nyelveket megalkották. 


Tehát a nyers erőfitogtatás kerülendő — de hogyan? Nézzük, mi történik, ha a Glyph osztály- 
hoz a következő elvont műveletet adjuk: 


void CheckMe (SpellingChecker6) 


A CheckMe-t (EllenőrizEngem) a Glyph valamennyi alosztályában a következőképpen ha- 
tározzuk meg: 


void GlyphAlosztaly: :CheckMe (SpellingCheckerg checker) ( 
checker.CheckGlyphAlosztaly (this) ; 
) 


A fenti kódban a GlyphaAlosztaly helyére a megfelelő alosztály neve írandó. Ez azt jelen- 
ti, hogy amikor a CheckMe hívására sor kerül, az adott alosztály ismert — végül is az egyik 
műveletében vagyunk. A SpellingChecker osztályfelület cserébe minden Glyph alosztály- 
hoz" tartalmaz egy CheckGlyphAlosztaly vagy hasonló műveletet. 





"9 Ha függvény-túlterhelést alkalmazunk, ezen tagfüggvények mindegyikének ugyanazt a nevet adhatjuk, hi- 
szen a paramétereik úgyis megkülönböztetik őket. Itt azért kaptak különböző nevet, hogy különbségeiket 
hangsúlyozzuk. 
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class SpellingChecker ( 
public: 
SpellingChecker ( ) ; 


virtual void CheckCharacter(Character" ) ; 
virtual void CheckRow(Row" ) ; 
virtual void CheckImage ( Imaget ) ; 


// ...és Így tovább 


Listcchar"og GetMisspellings(); 
protected: 
virtual bool IsMisspelled(const char"); 


private: 
char . currentWord (MAX WORD SIZE] ; 
Listcchart:  misspellings; 

1i 


A spellingcChecker ellenőrző művelete a Character képjelek esetében valahogy így 
festhet: 


void SpellingChecker: : CheckCharacter (Character? c) ( 
const char ch - c-sGetCharCode( ) ; 


if (isalpha(ch)) ( 
// betűkarakter hozzáfűzése a . currentWord-höz 


) else ( 
// a karakter nem betű 


if (IsMisspelled( currentWord)) ( 
// a  currentWord hozzáadása a  misspellings-hez 
-misspellings.Append(strdup(. currentWorá) ) ; 

) 


-currentWord[0] - "NO"; 
// a  currentWord visszaállítása a következő szó vizsgálatához 


Észrevehetjük, hogy a GetCharCode (LekérKarakterkód) művelet csak a Character Osz- 
tállyal működik, így a helyesírás-ellenőrző a különböző alosztályokhoz kapcsolódó műve- 
leteket anélkül végezheti el, hogy típusellenőrzést vagy -átalakítást kellene végeznie, va- 
gyis az objektumokat egyedileg kezelheti. 
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A CheckCharacter (EllenőrizKarakter) a betűkaraktereketa currentword ( aktuális- 
Szó) átmeneti tárban gyűjti össze. Ha nem betű karakterrel, például egy aláhúzásjellel talál- 
kozik, az IsMisspelled (HibásanírO művelet segítségével ellenőrzi a tárban levő szó 
helyesírását". Ha a szót helytelenül írták, a CneckCharacter hozzáadja azt a rosszul írt 
szavak listájához, majd kiüríti a currentword tárat, hogy helyet csináljon a következő 
szónak. A bejárás végeztével a helytelenül írt szavakat a GetMisspellings (Szerez- 
Helytelenek) művelettel kérdezhetjük le. 


Most már bejárhatjuk a dokumentumot: meghívjuk a CneckMe műveletet minden képjelre, 
argumentumként pedig a helyesírás-ellenőrzőt adjuk át neki, Ez minden képjelet azonosít 
a SpellingChecker számára, és az ellenőrzőt előre lépteti: 

SpellingChecker spellingChecker; 

Compositiont c; 


A 


Glyph" g; 
PreorderIterator i(c); 


for (i.First(); !i.IsDone(); i.Next())( 
g - i.CurrentlItem(); 
9g-:CheckMe(spellingChecker) ; 

) 


Az alábbi együttműködési diagram azt mutatja be, hogyan dolgoznak együtt a Karakter 
(Character) képjelek és a HelyesírásEllenőrző (Spell ingChecker) objektum: 

































































egykKarakter ("a") másikkKarakter (" ") egyHelyesírásEllenőrző 
EllenőrizéngemfegyHelyesírásEllenőrző) 
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Szerezkarakterí) 
Ég 177 KAZESE RNS SAVESZNTÉ s tááettáeó sáásatttátaáse , SABB ( 
44] 
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"Az IsMisspelled valósítja meg a helyesírás-ellenőrző algoritmust, amit itt nem részletezünk, hiszen függetlenítet- 
tük a Lexi felépítésétől. A SpellingChecker-ből alosztályokat létrehozva, vagy a Stratégia mintát (a 2.3 részben, 
a formázással kapcsolatban bemutatott módon) alkalmazva különböző algoritmusokat támogathatunk. 
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A módszer megfelel a helyesírási hibák megtalálására, de hogyan segíthet abban, hogy 
többféle elemzést támogassunk? Jelenleg úgy tűnik, a Glyph-et és alosztályait minden eset- 
ben ki kell egészítenünk egy CheckMe (SpellingCheckers ) -hez hasonló művelettel, ha 
új elemzési módszert építünk a programba. Ez így is van, már ha ragaszkodunk ahhoz, 
hogy minden elemzéshez önálló osztály tartozzon. Azt viszont semmi nem indokolja, hogy 
ezen osztályoknak ne legyen közös felülete. Ha készítünk egy ilyet, kihasználhatjuk a több- 
alakúság előnyeit, vagyis a CheckMe (SpellingCheckerg)-hez hasonló, az elemzési 
módtól függő műveleteket egy olyan, elemzésfüggetlen művelettel válthatjuk fel, ami álta- 
lánosabb paramétert vár. 


A Visitor osztály és alosztályai 

A látogató (visitor) kifejezéssel általánosságban olyan objektumok osztályára utalunk a könyv- 
ben, amelyek bejárás közben más objektumokat , látogatnak meg" és ott valamilyen művele- 
tet végeznek?, Ebben az esetben egy olyan Látogató (Visitor) osztályt készítünk, ami 
a képjelek ,meglátogatásának" elvont felületét határozza meg: 


class Visitor ( 

public: 
virtual void VisitCharacter(Character") ( ) 
virtual void VisitRow(RowY) ( ) 
virtual void VisitImage(Imager) ( ) 


// és így tovább... 
hi; 


A Visitor konkrét alosztályai különböző elemzéseket végeznek. A helyesírás-ellenőrzés 
elvégzésére például létrehozhatunk egy SpellingCheckingVisitor (HelyesírásEllen- 
őrzőLátogató) alosztályt, az elválasztásra pedig egy Hyphenationvisitor (Elválasztás- 
Látogató) nevűt. A SpellingCheckingvVisitor osztályt pontosan ugyanúgy valósítanánk 
meg, mint feljebb a SpellingChecker-t, azzal az eltéréssel, hogy a műveletek neve az ál- 
talánosabb Visitor felületre utalnának, például a checkCharacter a VisitCharacter 
(LátogatkKarakter) nevet kapná. 


Mivel a CheckMe azon látogatók számára, akik nem ellenőriznek semmit, nem megfelelő, 
a helyénvalóbb Accept (Elfogad) nevet adjuk neki. Argumentumának is meg kell változnia 
(Visitors), hogy tükrözze, bármilyen látogatót elfogad. Így egy új elemzési módszer hoz- 
záadásához csak létre kell hoznunk a Visitor egy új alosztályát — egyetlen képjel- 
osztályhoz sem kell hozzányúlnunk. A jövőbeni kiegészítések támogatásához ezt az egyet- 
len műveletet kell hozzáadnunk a Glyph-hez és alosztályaihoz. 


Már láttuk, hogyan működik a helyesírás-ellenőrzés. A Hyphenationvisitor-ban a szö- 
veggyűjtéshez hasonló megközelítést alkalmazunk, de amikor annak VisitCharacter 





12 A meglátogat" kifejezés az ,elemez" általánosabb változata, amit a hamarosan bemutatandó tervezési minta 
szóhasználatában alkalmazunk. 
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művelete megtalált egy teljes szót, kissé másképp működik. Nem ellenőrzi, hogy helyesen 
írták-e a szót, hanem egy elválasztási algoritmussal megállapítja benne a lehetséges elvá- 
lasztási helyeket, ha vannak ilyenek. Ezután minden elválasztási ponton beszúr egy elválasz- 
tó képjelet az összetételbe. Az elválasztó képjelek a Glyph osztály Discretionary (Elvá- 
lasztó) alosztályának példányai. 


Az elválasztó képjelek kétféleképpen jelenhetnek meg, attól függően, hogy a sor utolsó ka- 
rakteréről van-e szó. Ha igen, az elválasztó egy kötőjel formáját ölti, ha nem, rejtett elem 
lesz belőle. Az elválasztó szülője (egy Row, vagyis Sor objektum) ellenőrzésével állapítja 
meg, hogy az utolsó gyermek-e a sorban, és ezt az ellenőrzést mindig elvégzi, amikor meg- 
hívják, hogy rajzolja ki magát vagy számítsa ki a helyét. A formázási módszer az elválasztó- 
kat ugyanúgy kezeli, mint az üreshelyeket (térközöket), vagyis lehetséges sorzáró karakte- 
rekként. A következő diagram azt mutatja, hogyan jelenhet meg egy beágyazott elválasztó. 


(an ól ha (sm) aga) fi "o" ( nye) 


ÁLNEÉG KKE REM eszes ZA 4 ISS SZZSZZEZZ n 
jaluminum alloy vgy Taluminum al- ! 
1 





A Látogató tervezési minta 

Amit fentebb vázoltunk, az egy példa a Látogató (Visitor) tervezési minta alkalmazására. 
E mintában a korábban bemutatott Látogató (Visitor) osztály és alosztályai játszanak kulcs- 
szerepet. A minta lényege, hogy segítségével a képjelszerkezetek tetszőleges számú elem- 
zését támogathatjuk, anélkül, hogy magukat a képjelosztályokat módosítanunk kellene. 
A látogatók másik hasznos szolgáltatása, hogy nem csak a fentebb bemutatott, összetétel tí- 
pusú szerkezetekre alkalmazhatók, hanem bármilyen objektumszerkezetre, vagyis halma- 
zokra, listákra, sőt, irányított körmentes gráfokra is. Ráadásul a látogató által meglátogatha- 
tó osztályok nem feltétlenül kell, hogy egy közös szülőosztályon keresztül kapcsolatban 
álljanak egymással, vagyis a látogatók osztályhierarchiákon átívelve is használhatók. 


A látogató minta alkalmazása előtt egy fontos kérdést kell feltennnük magunknak: mely 
osztályhierarchiák változnak majd a leggyakrabban? A minta ugyanis akkor hajtja a legtöbb 
hasznot, ha a stabil osztályszerkezettel rendelkező objektumokon sokféle műveletet szeret- 
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nénk végrehajtani. Egy új látogató hozzáadása nem igényli, hogy hozzányúljunk ehhez az 
osztályszerkezethez, ami különösen akkor jön jól, ha a hierarchia nagy méretű. Amikor 
azonban a szerkezethez új alosztályokat adunk, minden látogató felületet frissítenünk kell, 
hogy tartalmazzák az új osztály Visit . . . (Látogat . . .) műveletét. Példánkban ez azt je- 
lenti, hogy ha a G1yph-ből Izé néven egy új osztályt hozunk létre, a Visitor-t és annak al- 
osztályait is módosítanunk kell, hogy tartalmazzák a LátogatIzé műveletet. Jelenlegi ter- 
vezési céljaink azonban inkább azt valószínűsítik, hogy a Lexit inkább új elemző műveletek- 
kel, semmint új képjelekkel bővítjük majd, így a Látogató minta megfelel az igényeinknek. 


2.9 Összefoglalás 


A Lexi tervezése során nyolc tervezési mintát alkalmaztunk: 


s az Összetétel mintát a dokumentum fizikai szerkezetének ábrázolására, 

e a Stratégia mintát a különböző formázási algoritmusok támogatására, 

e a Díszítő mintát a felhasználói felület finomítására, 

e az Elvont gyár mintát többféle megjelenítési szabvány támogatására, 

s a Híd mintát a különféle ablakkezelő rendszereken való futáshoz, 

e a Parancs mintát a visszavonható felhasználói műveletekhez, 

e a Bejáró mintát az objektumszerkezetek eléréséhez és bejárásához, 

e valamint a Látogató mintát, ami tetszőleges számú elemzési képesség beépítését tette 
lehetővé anélkül, hogy a dokumentumszerkezet megvalósítását bonyolította volna. 


Egyik tervezési minta alkalmazhatósága sem szorítkozik a Lexihez hasonló szövegszerkesz- 
tő programokra. A legtöbb alkalmazásban lehetőség nyílik akár többnek a használatára is, 
persze nem feltétlenül ugyanezeket a feladatokat megoldandó. Egy pénzügyi elemző prog- 
ramban jó szolgálatot tehet az Összetétel minta, a befektetési portfoliók összeállításánál; 
egy fordítóprogramban a Stratégia mintát alkalmazhatjuk, hogy különböző célrendszerekre 
más-más regiszterfoglalási módszert biztosítsunk; a grafikus felhasználói felületű alkalma- 
zásokban pedig valószínűleg szükségünk lesz legalább a Díszítő és a Parancs mintára, mint 
ahogy az itt bemutatott szövegszerkesztő programban is. 





Bár a Lexi kapcsán számos tervezési kérdés felmerült, ezeken kívül még sok létezik, ame- 
lyeket nem érintettünk. A könyvben azonban nem csak az említett nyolc tervezési mintát 
tárgyaljuk, és mindegyik ismertetésénél érdemes elgondolkodni azon, hogyan hasznosít- 
hatnánk a Lexi esetében — vagy még inkább saját programjainkban. 


A tervezési minták katalógusa 


Létrehozási minták 


A létrehozási minták a példányosítási folyamat elvont ábrázolásai. Segítenek függetleníteni 
Az osztálylétrehozási minták öröklés útján módosítják azt az osztályt, amelyből példány ké- 
szül, míg az objektum-létrehozási minták átruházzák a példányosítást egy másik objektumra. 


A létrehozási minták akkor válnak fontossá, amikor a rendszer a fejlődés során elkezd job- 
ban függni az objektumok összeállításától, mint az osztályörökléstől. Amikor ez megtörté- 
nik, a lényeg áthelyeződik a rögzített viselkedéshalmaz állandó jellegű bekódolásáról az 
alapvető viselkedésmódok olyan kisebb halmazának meghatározására, amely beépíthető 
akárhány összetettebb halmazba. Ezáltal adott viselkedésű objektumok létrehozásához 
többre lesz szükség puszta osztálypéldányosításnál. 


Ezen mintáknak két visszatérő ismérve van. Az első, hogy mindegyikbe be van ágyazva an- 
nak ismerete, hogy a rendszer valójában pontosan mely osztályokat használja, a másik, 
hogy elrejtik, hogy ezen osztályok példányait hogyan hozza létre és rakja össze a rendszer. 
Nagyjából minden, amit a rendszer ezekről az objektumokról tud, az, hogy milyen felületet 
határoznak meg hozzájuk az elvont osztályok. Ennek következtében a létrehozási minták 
nagy rugalmasságot tesznek lehetővé annak terén, hogy mit hozunk létre, ki hozza azt lét- 
re, hogyan és mikor. Így kialakítható egy olyan rendszer, amely rendkívül változatos felépí- 
tésű és szerepű objektumokat , termel". A kialakítás lehet statikus (azaz fordítási időben 
megadott) vagy dinamikus (futásidőben megadott). 


A létrehozási osztályok néha versenyeznek egymással. Vannak például olyan esetek, amikor 
a Prototípus vagy az Elvont gyár gazdaságosan használható, máskor viszont kiegészítenek 
más osztályokat: az Építő más mintákat felhasználva valósíthatja meg, mely összetevők legye- 
nek elkészítve. A Prototípus minta saját megvalósításához az Egyke mintát használhatja fel. 
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Mivel a létrehozási minták rendkívül közeli kapcsolatban állnak egymással, mind az ötöt 
együtt tanulmányozzuk, hogy megtudjuk, miben hasonlítanak, és miben különböznek. 
Megvalósításuk szemléltetésére egy közös példát adunk — egy számítógépes játékhoz ho- 
zunk létre egy labirintust. A labirintus és a játék mindegyik mintánál más lesz egy kicsit. Né- 
ha csak az lesz a feladat, hogy megtaláljuk a kiutat a labirintusból, ekkor a játékos valószí- 
nűleg csak a labirintus helyi képét fogja látni. Néha a labirintuson belül feladatokat is meg 
kell oldani és veszélyeket kell leküzdeni, és ezeknél a játékoknál a labirintus egy részének 
térképe is megtekinthető lesz. 


Számos olyan részletet figyelmen kívül fogunk hagyni, hogy mi lehet a labirintuson belül, 
és hogy a labirintusjátékot egy vagy több játékos játszhatja-e. Ehelyett arra összpontosítunk, 
hogyan kell létrehozni a labirintust, amelyet ,szobák" halmazaként alakítunk ki. Mindegyik 
szoba tudja, hogy kik veszik körül, kik a szomszédai. A lehetséges szomszédok: egy másik 
szoba, egy fal, vagy egy ajtó egy másik szobába. 


A Room (Szoba), a Door (Ajtó) és a Wa11 (Fal) osztály határozza meg a labirintus alkotóele- 
meit minden példában. Az osztályoknak csak azon részeit határozzuk meg, amelyek fonto- 
sak a labirintus létrehozása szempontjából, és figyelmen kívül hagyjuk a játékosokat, a labi- 
rintusban való mozgáshoz és az ott látottak megjelenítéséhez szükséges műveleteket és 
más olyan, egyébként fontos szolgáltatásokat, amelyek magának a labirintusnak az elkészí- 
téséhez nem létfontosságúak. Az alábbi ábra az osztályok közötti kapcsolatokat mutatja: 


















] (7 
] 








Enter() Enter() Enter() 
GetSide() isOpen 






AddRoom() 
RoomNo() 





roomNumber 


Mindegyik szobának négy oldala van. A Cs nyelven történő megvalósításkor a Direction 
felsorolás segítségével adjuk meg a szoba északi, déli, keleti és nyugati oldalát: 


enum Direction (North, South, East, West); 


A Smalltalk megvalósításban az irányok jelölésére a megfelelő jeleket kell használni. 
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A MapgSsite (HelyTérkép) osztály a labirintus összes alkotóelemének közös elvont osztálya. 
A példa egyszerűsítéséhez a MapSite osztály csak egy műveletet (Enter) határoz meg, 
amelynek jelentése attól függ, milyen adatot viszünk be. Ha szobát, akkor megváltozik 
a hely. Ha megpróbálunk belépni egy ajtón, két dolog történhet: ha az ajtó nyitva van, belé- 
pünk a következő szobába, ha pedig zárva, beverjük az orrunkat. 


class MapSite ( 
public: 

virtual void Enter() - 0; 
tt 


Az Enter egyszerű alapot ad a játék kifinomultabb műveleteihez. Ha például valamelyik 
szobában vagyunk, és a , Keletre! parancsot adjuk ki, a játék egyszerűen meg tudja hatá- 
rozni, hogy melyik MapSite osztály esik közvetlenül keletre, és meghívja rá az Enter mű- 
veletet. Az alosztályfüggő Enter művelet kitalálja, hogy helyet változtattunk-e, vagy az or- 
runkat vertük be, Az igazi játékban az Enter argumentumként megkaphatná a játékos ob- 
jektumot is, amely a labirintusban mozog. 


A Room a MapSite osztály konkrét alosztálya, ez határozza meg a labirintus alkotóelemei 
közti főbb kapcsolatokat. A MapSite osztály többi objektumára való hivatkozásokat tartal- 
maz, és tárolja a szobaszámot. A labirintusban a szobákat a szobaszámmal lehet azonosítani. 


elass Room : public MapSite ( 
public: 
Room(int roomNo) ; 


MapSitetr GetSide(Direction) const; 
void SetSide(Direction, MapSitet); 


virtual void Enter(); 


private: 
MapSiter  sides[4]; // falak 
int . roomNumber ; 


); 

Az alábbi osztályok a szoba egyes oldalain található ajtókat, illetve falakat jelképezik. 
class Wall : public MapSite ( 
public: 


Wall(); 


virtual void Enter(); 
); 
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class Door : public MapSite ( 
public: 
Door(Roomt - 0, Roomtr - 0); 


virtual void Enter(); 
Room? OtherSideFrom(Roomt ) ; 


private: 
Roomt . rooml1 ; 
Roomt . room2 ; 
bool  isOpen; 
17 


Több dologról is tudnunk kell, nem csak a labirintus alkotóelemeiről, ezért meg kell hatá- 
roznunk egy Maze (Labirintus) nevű osztályt is, amely a szobák összességét jelképezi. 
A Maze osztály képes egy adott szobát is megtalálni a szobaszám alapján, a RoomNo 
(SzobaSzám) művelet segítségével. 


class Maze ( 
public: 
Maze(); 


void AddRoom(Roomt ) ; 
Roomt RoomNo(int) const; 
private: 
LA 
tj 


A RoomNo lineáris keresés, hasítótábla (kivonattábla), de akár egyszerű tömb használatával 
is tud keresni, de ilyen részletekkel most nem foglalkozunk. Ehelyett arra összpontosítunk, 
hogyan adhatjuk meg egy labirintusobjektum alkotóelemeit. 


Egy másik általunk meghatározandó osztály a MazeGame (abirintusjáték), amely magát 
a labirintust hozza létre. A labirintus létrehozásának egyik leglogikusabb módja, ha olyan 
műveletek sorával készítjük el, amelyek alkotóelemeket adnak a labirintushoz, majd össze- 


kapcsolják azokat. A következő tagfüggvény például egy két szobából és egy köztük lévő 
ajtóból álló labirintust hoz létre: 


Mazet MazeGame: :CreateMaze () ( 
Mazet aMaze - new Maze; 
Roomt r1 - new Room(1); 
Roomt r2 - new Room(2) ; 
Door" theDoor - new Door(ri, r2); 


aMaze-5AddíRoom(r1) ; 
aMaze-5AddRoom( r2) ; 
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r1-:sSetSide 
r1-sSetSide 
r1-sSetSide 
r1-sSetSide 


North, new Wall); 
East, theDoor); 
South, new Wall); 
West, new Wall); 


r2-:5SetSide(North, new Wall); 
r2-5SetSide(East, new Wall); 
r2-:SetSide(South, new Wall); 
r2-:SetSide(West, theDoor) ; 


return aMaze; 


) 


Ez a függvény meglehetősen összetett, főleg ha azt is figyelembe vesszük, hogy semmi 
mást nem tesz, csak létrehoz egy kétszobás labirintust. Nyilvánvalóan van mód az egysze- 
rűsítésére. A Room konstruktor például előkészítheti a szoba oldalait falakkal, de ezzel csak 
máshová kerül át a kód. Az igazi gond ezzel a tagfüggvénnyel nem a mérete, hanem a ru- 
galmatlansága, mivel mereven kódolja be a labirintus elrendezését. Ha módosítani akarjuk 
a labirintus kialakítását, ezt a tagfüggvényt módosítanunk kell, akár felülbírálva azt (ami az 
egész újbóli megvalósítását jelenti), akár egyes részeit megváltoztatva (ami viszont növeli 
a hibákra való hajlamot, és nem teszi lehetővé az újrahasznosításO. 


A létrehozási minták azt mutatják meg, hogyan lehet ezt az elrendezést rugalmasabbá — de 
nem feltétlenül kisebbé — tenni; nevezetesen megkönnyítik a labirintus elemeit meghatáro- 
zó osztályok módosítását. 


Tételezzük fel, hogy egy már létező labirintuselrendezést szeretnénk felhasználni egy új játék- 
hoz, amely (többek közöt) elvarázsolt labirintusokat is tartalmaz. Az elvarázsolt labirintus já- 
tékban új elemek is vannak, például a DoorNeedingsSpel1 (AjtóVarázsigével) egy olyan ajtó, 
amelyet csak varázsigével lehet bezárni, majd utána kinyitni, és az EnchantedRoom 
(ElvarázsoltSzoba) egy olyan szoba, amelyben szokatlan dolgok, például bűvös kulcsok vagy 
varázsigék vannak. Hogyan lehet egyszerűen módosítani a CreateMaze (Létrehozlabirintus) 
műveletet úgy, hogy olyan labirintust hozzon létre, amelyben megtalálhatók ezek az új objek- 
tumosztályok? 


Ebben az esetben a módosítások legfőbb gátja a példányosítandó osztályok merev kódolá- 
sa. A létrehozási minták különféle módszereket biztosítanak a kifejezett hivatkozások pél- 
dányosító kódból konkrét osztályokba történő áthelyezésére: 


e Ha a cCreateMaze konstruktorok helyett virtuális függvényeket meghívva hozza létre 
a szükséges szobákat, falakat és ajtókat, akkor a MazeGame alosztályait létrehozva és 
ezeket a virtuális függvényeket felülírva módosíthatók a példányosított osztályok. 
Ezt a megközelítést mutatja be a Gyártófüggvény minta (Factory Method). 

e Ha a CreateMaze paraméterként kapott valamilyen objektumot a szobák, falak és 
ajtók létrehozásához, akkor a szobák, falak és ajtók osztályait úgy lehet megváltoz- 
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tatni, ha egy másik paramétert adunk át a CreateMaze osztálynak. Erre jó példa az 
Elvont gyár (Abstract Factory) minta. 

" Ha a CreateMaze olyan objektumot kapott, amely egy teljes új labirintust képes lét- 
rehozni, műveleteket használva a szobák, ajtók és falak hozzáadására a felépítendő 
labirintushoz, öröklés útján módosíthatjuk a labirintus elemeit vagy a labirintus fel- 
építésének módját. Erre jó példa a Építő (Builder) minta. 

" Ha a CreateMaze osztály paraméterei különféle prototípus jellegű szoba-, ajtó- és 
falobjektumok, amelyeket aztán lemásol, és úgy ad a labirintushoz, a labirintus fel- 
építése ezen prototípus jellegű objektumok más objektumokkal való lecserélésével 
módosítható. Erre jó példa a Prototípus (Prototype) minta. 


A fennmaradó létrehozási minta, az Egyke (Singleton) azt biztosíthatja, hogy játékonként 
csak egyetlen labirintus legyen, és a játék minden objektumának legyen hozzá olvasási en- 
gedélye anélkül, hogy globális változókhoz vagy függvényekhez kellene folyamodni, ezen- 
kívül megkönnyíti a labirintus bővítését vagy lecserélését anélkül, hogy hozzá kellene nyúl- 
ni a már meglévő kódhoz. 


Elvont gyár 


Objektum-létrehozási minta 
Cél 


Kapcsolódó vagy egymástól függő objektumok családjának létrehozására szolgáló felületet 
biztosítani a konkrét osztályok megadása nélkül. 


Egyéb nevek 


Abstract Factory, Kit (Készle) 


Feladat 


Vegyünk egy olyan felhasználói felületi elemkészletet, amely többféle megjelenítési szab- 
ványt támogat — amilyen például a Motif vagy a Presentation Manager. Ezekben máshogy 
néznek ki és viselkednek a felhasználói felület grafikus elemei (vezérlők, widget), például 
a gördítősávok, az ablakok és a gombok. Ha a különféle megjelenítési szabványok között 
hordozható alkalmazásokat szeretnénk készíteni, az alkalmazásokba nem lehet ,bedrótozni" 
a felhasználói felületi elemeket, mert a kifejezetten egy adott szabványhoz tartozó elemosztá- 
lyok példányosítása az alkalmazásban megnehezíti a megjelenítés későbbi megváltoztatását. 


Elvont gyár 
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Ezt a problémát úgy oldhatjuk meg, ha olyan elvont VezérlőGyár (WidgetFactory) osztályt 
készítünk, amely egy felületet határoz meg minden alapvető elemfajta létrehozásához. 
Emellett minden elemfajtához is tartozik egy elvont osztály, az egyes megjelenítési szabvá- 
nyokhoz tartozó elemeket pedig konkrét alosztályok valósítják meg. A VezérlőGyár felüle- 
tének van egy olyan művelete, amely minden elvont elemosztályhoz egy új vezérlőobjektu- 
mot ad vissza. Az ügyfelek ezeket a műveleteket meghívva kérhetnek elempéldányokat, de 
nem tudják, hogy pontosan mely konkrét osztályokat használják, így függetlenek marad- 
nak az éppen használt megjelenítési szabványtól. 


VezérlóGyár 1 ügyfél 
LétrehozGördítóSáv() 
LótrohozAblak() LAK 


--s[/ PMAblak ]  [/MotifAblak e - - 
















































































MotifVezérlőGyár [- - PIMVezérlőGyár 1... ; 
LétrehozGördítőSáv() LétrehozGördítőSáv() ; 
LétrehozAblak() LétrehozAblak() , 














MotifGördítőSávi 











A VezérlőGyár osztály minden megjelenítési szabványhoz konkrét alosztállyal rendelkezik. 
Az alosztályok azokat a műveleteket valósítják meg, amelyek az adott megjelenítési szab- 
ványhoz szükséges felületelemek létrehozásához kellenek. Például a MotifVezérlőGyár 
(MotifWidgetFactory) alosztály LétrehozGördítőSáv (CreateScrollBar) művelete egy Motif 
gördítősávot példányosít és ad vissza, a megfelelő PMVezérlőGyár (PMWidgetFactory) al- 
osztályon végzett művelet pedig egy Presentation Manager gördítősávot. Az ügyfelek kizá- 
rólag a VezérlőGyár felületen keresztül hoznak létre felületelemeket, és nem tudnak sem- 
mit azokról az osztályokról, amelyek a konkrét megjelenítés felületelemeit valósítják meg. 
Más szavakkal: az ügyfeleknek nincs más teendőjük, mint rábízni magukat egy olyan felü- 
letre, amelyet az elvont osztályok és nem a megfelelő konkrét osztályok hoznak létre. 


A VezérlőGyár függőségeket is kényszerít a konkrét vezérlőosztályokra. A Motif gördítő- 
sávok Motif gombbal és Motif szövegszerkesztővel használhatók, és ezt a megszorítást 
a MotifVezérlőGyár használatának következményeként automatikusan kikényszeríti 
a program. 
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Alkalmazhatóság 


Az Elvont gyár minta az alábbi esetekben használható: 


. A rendszernek függetlennek kell lennie attól, hogy , termékeit" hogyan hozza létre, 
állítja össze és jeleníti meg. 

, A rendszert úgy kell beállítani, hogy a ,termékcsaládok" egyikével használható le- 
gyen. 

e Az egy családhoz tartozó termékobjektumokat együttes használatra tervezték, és ezt 
a megszorítást ki kell kényszerítenünk. 

e Termékek osztálykönyvtárát szeretnénk létrehozni, de csak a felületeiket szeretnénk 
felfedni, megvalósításukat nem. 




























































































Szerkezet 
ElvontGyár  1-a. Ügyfél 
Lárahoztámákő0 FlvontTarméka 
.-- e] TermékAZ ]  ( TermékAT h6--. 
KonkrétGyári  1-, [7 Konkrétgyárz ]......... ; ; 
LétrehozTermékA() , LétrehozTermékAt ! : 
LétrehoztermékBí) : LárrohozrarmékBŰ) ] : ElvontTermékB ; 
Résztvevők 


s  ElvontGyár (VezérlőGyán 
— Elvont termékobjektumokat létrehozó műveletek számára vezet be felületet. 
e  KonkrétGyár (MotifVezérlőGyár, PMvezérlőGyár) 
— Megvalósítja a konkrét termékobjektumokat létrehozó műveleteket. 
s  ElvontTermék (Ablak, GördítőSáv) 
- Egy adott típusú termékobjektumhoz hoz létre felületet. 
e  KonkrétTermék (MotifAblak, MotifGördítőSáv) 
-— A megfelelő konkrét gyár (factory) által létrehozandó termékobjektumot határoz- 
za meg. 
-— Megvalósítja az ElvontTermék felületet. 
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s Ügyfél 
— Csak az ElvontGyár vagy az ElvontTermék osztály által meghatározott felületeket 
használja. 


Együttműködés 


e Normál esetben a program futásidőben egy példányt hoz létre a KonkrétGyár osz- 
tályból. Ez a konkrét gyár olyan termékobjektumokat hoz létre, amelyeknek egy 
adott megvalósításuk van. Ha más termékobjektumokat szeretnénk létrehozni, az 
ügyfeleknek más konkrét gyárakat kell használniuk. 

e Az ElvontGyár a KonkrétGyár alosztályra bízza a termékobjektumok létrehozását. 


Következmények 


Az Elvont gyár minta előnyei és hátrányai a következők: 


1. Elszigeteli a konkrét osztályokat. Az Elvont gyár minta segíti az alkalmazások által 
létrehozott objektumosztályok kezelését. Mivel a gyár tartalmazza a termékobjektu- 
mok létrehozásának felelősségét és folyamatát, elszigeteli az ügyfeleket a megvalósí- 
tási osztályoktól. Az ügyfelek saját elvont felületükön át kezelik a példányokat. 
A termékosztálynevek el vannak szigetelve a konkrét gyár megvalósításában, és nem 
jelennek meg az ügyfél kódjában. 

2. Megkönnyíti a termékcsaládok cseréjét. A konkrét gyár osztálya egy alkalmazásban 
csak egyszer jelenik meg - akkor, amikor példányosítják. Ez megkönnyíti az alkal- 
mazás által használt konkrét gyár megváltoztatását. A különféle termékegyüttesek 
használatához nem kell mást tenni, mint megváltoztatni a konkrét gyárat. Mivel az 
elvont gyárak teljes termékcsaládokat állítanak elő, egyszerre megváltozik a teljes 
termékcsalád. A felhasználói felületes példában pusztán a megfelelő gyárobjektu- 
mok közötti átkapcsolással és a felületet újra létrehozva átválthatunk a Motif felület- 
elemekről a Presentation Manager elemekre. 

3. Biztosítja a termékek közti egységességet. Amikor egy családon belül együttműkö- 
désre tervezett termékobjektumok vannak, fontos, hogy az alkalmazások egyidőben 
csak egy termékcsaládba tartozó objektumokat használjanak. Az ElvontGyár leegy- 
szerűsíti ennek kikényszerítését. 

4. Az új termékfajták támogatása nehézségekbe ütközik. Az elvont gyárak kibővítése 
újfajta termékek létrehozására nem könnyű. Ennek az az oka, hogy az ElvontGyár 
felület rögzíti a létrehozható termékeket. Az újfajta termékek támogatásához ki kell 
bővíteni a gyár felületét, amihez meg kell változtatni az ElvontGyár osztályt és annak 
minden alosztályát. A probléma egyik megoldását a Megvalósítás rész ismerteti. 
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Megvalósítás 


Az alábbiakban az Elvont gyár minta megvalósításának néhány módját mutatjuk be. 


1. Gyárak mint egykék. Egy alkalmazásnak jellemzően csak egy KonkrétGyár példány- 


ra van szüksége termékcsaládonként, így azokat általában a legjobb Egyke formájá- 
ban megvalósítani. 


. A termékek létrehozása. Az ElvontGyár csak a felületet adja meg, amelyre a termé- 


kek előállításához szükség van. A termékek konkrét létrehozását a KonkrétTermék 
alosztályok végzik. Ennek legáltalánosabb módszere az, hogy minden termékhez 
egy külön gyártófüggvényt határozunk meg (lásd a Gyártófüggvény mintát). A konk- 
rét gyárak termékeiket a gyártófüggvény felülírásával állítják elő. Miközben ez 
a megvalósítás egyszerű, új konkrét gyár alosztály kell minden termékcsaládhoz, ak- 
kor is, ha a termékcsaládok csak kismértékben térnek el egymástól. 
Ha sok termékcsaládra lehet szükség, a konkrét gyár megvalósítható a Prototípus 
minta segítségével is. A konkrét gyár a családba tartozó minden termékhez külön 
prototípus-példányt használva készíthető elő, és az új termékek a prototípus klóno- 
zásával jönnek létre. A Prototípus alapú megközelítést használva nincs szükség min- 
den új termékcsaládhoz új konkrét gyár osztályra. 
Az alábbi példa egy Prototípus alapú gyár Smalltalk nyelven történő megvalósítását 
szemlélteti. A konkrét gyár egy partCatalog nevű katalógusban tárolja a klóno- 
zandó prototípusokat. A make : metódus beolvassa és klónozza a prototípust: 

make: partName 

" (partCatalog at: partName) copy 

Új alkatrészeket a konkrét gyár metódusával vehetünk fel a katalógusba. 

addPart: partTemplate named: partName 

partCatalog at: partName put: partTemplate 

A prototípusokat egy szimbólummal azonosítva lehet a gyárhoz adni: 

aFactory addPart: aPrototype named: HACMEWidget 
A Prototípus alapú megközelítés olyan nyelveken lehetséges, amelyek az osztályo- 
kat első osztályú objektumokként kezelik (ilyen például a Smalltalk és az Objective 
0). Ezeken a nyelveken az osztályt úgy kell elképzelni, mint egy olyan csökevényes 
gyárat, ami csak egyfajta terméket állít elő. Az osztályokat olyan konkrét gyárak bel- 
sejében lehet tárolni, amelyek a különböző konkrét termékeket változókban állítják 
elő, nagyjából úgy, mint a prototípusok. Az osztályok egy konkrét gyár nevében 
hoznak létre új példányokat. Új gyárat egy konkrét gyár egy példányának termékosz- 
tályok útján történő előkészítésével lehet meghatározni, nem pedig alosztályok létre- 
hozásával. Ez a megközelítés kihasználja az egyes nyelvek szolgáltatásainak előnye- 
it, míg a tisztán Prototípus alapú megközelítés nyelvfüggetlen. 
Mint a fentebb említett Prototípus alapú gyárban a Smalltalk nyelvben, az osztály ala- 
pú változatban is egyetlen példányváltozó van (partCatalog), amely egy olyan 
katalógus vagy , szótár", amelynek kulcsa az alkatrész neve. A partcatalog nem 
klónozandó prototípusokat tárol, hanem termékosztályokat. A make: metódus eb- 
ben az esetben így néz ki: 
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make: partName 
" (partCatalog at: partName) new 

3. Bővíthető gyárak meghatározása. Az ElvontGyár általában minden általa előállítható 
terméktípushoz más-más műveletet határoz meg. A terméktípusokat a művelet alá- 
írása azonosítja. Új termékfajta hozzáadásához módosítani kell az ElvontGyár felüle- 
tet és az összes vele függőségi viszonyban lévő osztályt. 
Rugalmasabb, bár kevésbé biztonságos megoldás, ha az objektumokat létrehozó 
műveleteket látjuk el paraméterekkel. Ez a paraméter adja meg a létrehozandó ob- 
jektum típusát. Ez lehet osztályazonosító, egész szám, karakterlánc vagy bármi más, 
ami alkalmas a termékfajta azonosítására. Ezt a megközelítést használva az 
ElvontGyár osztálynak csak egyetlen ,Make" műveletre van szüksége, amely el van 
látva egy olyan paraméterrel, amely jelzi a létrehozandó objektum típusát. Ezt az el- 
járást használjuk a fentebb említett Prototípus és osztály alapú elvont gyárakban. 
Ezt a változatot a dinamikus jellegű nyelvekben — amilyen például a Smalltalk — 
könnyebb használni, mint a statikusokban, amilyen például a Ctt. A Ct4 nyelvben 
a megoldás csak akkor használható, ha minden objektum ugyanazt az elvont alap- 
osztályt használja, vagy ha a termékobjektumok az őket igénylő ügyfél útján bizton- 
ságosan a megfelelő típusra korlátozhatók. A Gyártófüggvény minta megvalósítását 
tárgyaló részben látni fogjuk, hogyan lehet ilyen paraméteres műveleteket megvaló- 
sítani a C4t nyelvben. 
De akkor is marad még egy gond, ha nem kell semmit sem korlátoznunk: az ügyfél- 
nek minden terméket ugyanazzal az elvont felülettel ad vissza a program, amelyet 
a visszatérési típus meghatároz, így az ügyfél nem lesz képes megkülönböztetni 
vagy biztonsággal felismerni a különféle termékosztályokat. Amennyiben az ügyfél- 
nek alosztályra jellemző műveletet kell végrehajtania, az elvont felületen keresztüli 
elérés lehetetlenné válik. Bár az ügyfél lefelé irányuló típusátalakítást (ez a Ctt 
nyelvben a dynamic. cast) tud végezni, ez nem mindig ésszerű és nem is mindig 
biztonságos, mivel az átalakítás meghiúsulhat. Rendszerint ez az ára a nagy rugal- 
masságú és bővíthető felületeknek. 


Példakód 


Az Elvont gyár minta segítségével most létrehozzuk azt a labirintust, amelyről a fejezet ele- 
jén volt szó. 


A MazeFactory (LabirintusGyár) osztály a labirintus elemeit tudja létrehozni. Szobákat, fa- 
lakat és szobák közti ajtókat épít. Használhatja olyan program, amely képes fájlból kiolvas- 
ni a labirintus , alaprajzát", és felépíteni abból a kívánt labirintust, vagy olyan, amely vélet- 
lenszerűen építi fel a labirintust. A labirintuskészítő programok argumentumként veszik fel 
a MazeFactory osztályt, hogy a programozók megadhassák a kialakítandó szobák, falak 
és ajtók osztályait. 
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class MazeFactory ( 
public: 


1; 


MazeFactory ( ) ; 


virtual MazeY MakeMaze() const 
( return new Maze; ) 
virtual Wally MakeWall() const 
( return new Wall; ) 
virtual Roomy MakeRoom(int n) const 
( return new Room(n); ) 
virtual Door?y MakeDoor(Roomt ri, Roomt r2) const 
( return new Door(ri, r2); ) 


Jusson eszünkbe, hogy a korábban bemutatott CreateMaze (Létrehozlabirintus) tagfügg- 
vény egy kis, két szobából és a köztük lévő ajtóból álló labirintust épít fel. A CreateMaze 
mereven bekódolja az osztályneveket, megnehezítve a különböző elemekből kialakított la- 


birintusok létrehozását. 


Íme a CreateMaze egy olyan változata, amely kijavítja ezt a hiányosságot, mégpedig úgy, 


hogy egy MazeFactory osztályt kap paraméterként: 


Mazet MazeGame: :CreateMaze (MazeFactoryg factory) ( 


) 


MazeY aMaze - factory.MakeMaze(); 

RoomYt ri - factory.MakeRoom(1); 

Roomt r2 - factory.MakeRoom(2) ; 

Doort aDoor - factory.MakeDoor(ri, r2); 


aMaze-sAddíRoom(r1) ; 
aMaze-sAddRoom(r2) ; 


r1-sSetSide(North, factory.MakeWall()); 
r1-5sSetSide(East, aDoor); 
r1-5SetSide(South, factory.MakeWall()); 
r1-5SetSide(West, factory.MakeWall()); 


r2-5SetSide(North, factory.MakeWall () ) ; 
r2-sSetSide(East, factory.MakeWall ()) ; 

r2-sSetSide(South, factory.MakeWall ()); 
r2-:5SetSide(West, aDoor); 


return aMaze; 


Az elvarázsolt labirintust építő EnchantedMazeFactory (ElvarázsoltlLabirintusGyár) osz- 
tályt a MazeFactory alosztályaként hozhatjuk létre. Az EnchantedMazeFactory külön- 
böző tagfüggvényeket bírál felül, és a Room, Wall stb. osztályok különböző alosztályait ad- 
ja vissza. 
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class EnchantedMazeFactory : public MazeFactory ( 
public: 
EnchantedMazeFactory ( ) ; 


virtual Roomt MakeRoom(int n) const 
( return new EnchantedRoom(ín, CastSpell()); ) 


virtual Doort MakeDoor(Roomt ri, RoomYt r2) const 
( return new DoorNeedingSpell(ri1, r2); ) 


protected: 
Spell" CastSpell() const; 
b; 


Most tételezzük fel azt, hogy olyan labirintusjátékot szeretnénk készíteni, amelyben az egyik 
szobában egy bomba van. Ha a bomba felrobban, az lerombolja (legalább) a falakat. Készít- 
hetünk olyan Room (Szoba) alosztályt, amely nyilvántartja, hogy van-e bomba az adott szo- 
bában, és ha igen, felrobbant-e már, Szükségünk lesz olyan Wal1 (Fal) alosztályra is, amely 
azt tartja nyilván, hogy megsérült-e a fal, és ha igen, hogyan. Legyen ezeknek az alosztályok- 
nak a neve RoomWithABomb (SzobaBombával!), illetve BombedwWa11 (LeromboltFa)). 


Az utolsó osztály, amelyet meghatározunk, a BombedMazeFactory (LeromboltLabirintus- 
Gyár). Ez a MazeFactory osztály alosztálya, és a BombedWal1 osztály lerombolt falait és 
a RoomWithABomb osztály bombát tartalmazó szobáit alakítja ki. A BombedMazeFactory 
alosztálynak csak két függvényt kell felülírnia: 


Wall" BombedMazeFactory::MakeWall () const ( 
return new BombedWall; 
) 


Roomt BombedMazeFactory::MakeRoom(int n) const ( 


return new RoomWithABomb (n) ; 


) 


Ha olyan egyszerű labirintust szeretnénk készíteni, amelyben bomba van, egyszerűen csak 
a BombedMazeFactory alosztállyal hívjuk meg a CreateMaze műveletet. 


MazeGame game; 
BombedMazeFactory factory; 


game . CreateMaze ( factory) ; 


A CreateMaze megkaphatja az EnchantedMazeFactory egy példányát is, így tudunk 
például elvarázsolt labirintust létrehozni. 
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Jegyezzük meg, hogy a MazeFactory nem más, mint gyártófüggvények puszta gyűjtemé- 
nye — ez az Elvont gyár minta legáltalánosabb megvalósítási módja —, valamint azt is, hogy 
a MazeFactory nem elvont osztály, így az ElvontGyár és a KonkrétGyár szerepét is betöl- 
ti, ami egy másik gyakori megvalósítása az Elvont gyár mintának egyszerű alkalmazások- 
ban. Mivel a MazeFactory olyan konkrét osztály, amely tisztán gyártófüggvényekből áll, 
új MazeFactory osztályt könnyű létrehozni úgy, bagy készítünk egy alosztályt, és felülír- 
juk a módosítandó műveleteket. 


A CreateMaze a SetSide (Beállítoldal) művelettel hozta létre a szobák oldalait. 
Ha a BombedMazeFactory alosztállyal hozza létre a szobákat, akkor a labirintus Bombed- 
Wall oldalú RoomWithABomb objektumokból áll össze. Ha a RoomWithABomb alosztály- 
nak a BombedWal1 alosztály egy tagját kell elérnie, akkor a falaira egy hivatkozást kell átala- 
kítania a Wal1" alosztályból a Bombedwall" alosztályba, Ez a lefelé irányuló átalakítás egé- 
szen addig biztonságos, amíg az argumentum tényleg egy BombedwWa1.1 alosztály, ami akkor 
igaz, ha a falakat kizárólag BombedMazeFactory alosztályokkal építjük fel. 


A dinamikus típusokkal dolgozó nyelvekben, amilyen például a Smalltalk, természetesen 
nincs szükség lefelé irányuló átalakításra, de futásidejű hibákat okozhat, ha Wa11 osztályba 
ütközünk ott, ahol a Wall osztály egy alosztályára számítunk. Ha a falakat az Elvont gyár 
minta segítségével építjük fel, az segít megelőzni az ilyen futásidejű hibákat, mivel biztosít- 
ja, hogy csak bizonyos típusú falakat lehessen létrehozni. 


Vizsgáljuk meg a MazeFactory egy Smalltalk nyelvű változatát, egy olyat, amelyben 
egyetlen make művelet van, amely az objektum típusát kapja paraméterül. Sőt mi több, 
a konkrét gyár tárolja a saját maga által létrehozott termékosztályokat. 


Először írjuk meg a CreateMaze megfelelőjét Smalltalk nyelven: 


createMaze: aFactory 
Il rooml room2 aDoor I 


rooml :- (aFactory make: troom) number: 1. 
room2 :- (aFactory make: troom) number: 2. 
aDoor :- (aFactory make: tdoor) from: roomi to: room2. 


rooml atSide: tnorth put: (aFactory make: twall). 
rooml atSide: teast put: aDoor. 

roomi atSide: tsouth put: (aFactory make: twall). 
rooml atSide: twest put: (aFactory make: twall). 
room2 atSide: tnorth put: (aFactory make: twall). 
room2 atSide: teast put: (aFactory make: twall). 
room2 atSide: tsouth put: (aFactory make: twall). 
room2 atSide: twest put: aDoor. 

" Maze new addRgoom: rooml; addRoom: room2; yourself 
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Amint a Megvalósítás részben már volt róla szó, a MazeFactory osztálynak csak a part- 
Catalog változó egy példányára van szüksége, hogy egy olyan szótárat biztosítson, 
amelynek a kulcsa az összetevő osztálya. Jusson eszünkbe az is, hogyan valósítottuk meg 
a make: metódust: 


make: partName 
" (partCatalog at: partName) new 


Most létrehozhatunk egy MazeFactory osztályt, és használhatjuk a createMaze megva- 
lósítására. A gyárat a MazeGame osztály createMazeFactory metódusának segítségével 
hozzuk létre. 


createMazeFactory 
" (MazeFactory new 
addPart: Wall named: twall; 
addPart: Room named: troom; 
addPart: Door named: tdoor; 
yourself) 


A BombedMazeFactory vagy az EnchantedMazeFactory alosztályt a kulcsokhoz kü- 
lönböző osztályokat társítva hozhatjuk létre. Egy EnchantedMazeFactory alosztály pél- 
dául így hozható létre: 


createMazeFactory 
" (MazeFactory new 
addPart: Wall named: twall; 
addPart: EnchantedRoom named: troom; 
addPart: DoorNeedingSpell named: tHdoor; 
yourself) 


Ismert felhasználások 


Az InterViews a ,Kit" utótagot használja [Lin92] az ElvontGyár osztályok megjelölésére; 
a WidgetkKit és DialogKit elvont gyárak például a megjelenítési szabványhoz kapcsolódó 
felhasználói felületi objektumok (vezérlők, illetve párbeszédablakok) létrehozására valók. 
Az InterViews tartalmaz egy olyan LayoutKit osztályt is, amely különféle összetett objektu- 
mokat állít elő, attól függően, hogy milyen elrendezésre van szükség. Például egy alapvető- 
en vízszintes elrendezésben másfajta összetett objektumokra lehet szükség a különféle do- 
kumentum-tájolásokhoz (álló vagy fekvő). 


Az ET4- IWGM88] az Elvont gyár mintát használja a különböző ablakkezelő rendszerek 
(például X Window és SunView) közötti hordozhatóság elérésére. A WindowSystem elvont 
alaposztály az ablakrendszer erőforrásait (például MakeWindow, MakeFont, MakeColor) 
jelképező objektumok létrehozására szolgáló felületet határozza meg. A konkrét alosztály- 
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ok egy-egy ablakrendszer felületét valósítják meg. Futásidőben az ET: abból a konkrét 
WindowsSystem alosztályból hoz létre egy példányt, amely a konkrét rendszererőforrás-ob- 
jektumokat állítja elő. 


Kapcsolódó minták 


Az ElvontGyár osztályokat gyakran gyártófüggvényekkel valósítják meg (Gyártófüggvény 
minta), de megvalósíthatók a Prototípus minta segítségével is. 


A konkrét gyár gyakran Egyke. 


PA 
Fo 4 

Építő 

Objektum-létrehozási minta 


Egyéb nevek 


Builder 


Cél 


Az összetett objektumok felépítésének függetlenítése az ábrázolásuktól, így ugyanazzal az 
építési folyamattal különböző ábrázolásokat hozhatunk létre. 


Feladat 


Az RTF (Rich Text Format) dokumentumcsere-formátumot olvasó alkalmazásnak képesnek 
kell lennie az RTF sok egyéb szövegformátumba való átalakítására is. Az olvasóprogram át- 
alakíthatja az RTF dokumentumot sima ASCII szöveggé vagy interaktív módon szerkeszthe- 
tő szövegkezelő felületelemmé. A gond azonban az, hogy a lehetséges átalakítások száma 
korlátlan, így az olvasóprogram módosítása nélkül is egyszerűen kell, hogy új átalakítást 
adhassunk meg. 


Egy megoldás lehet, ha az RTFOlvasó (RTFReader) osztályt az RTF formátumot másfajta 
szövegmegjelenítési formátumra átalakító SzövegÁtalakító (TextConverter) objektummal 
állítjuk be. Amikor az RTFOlvasó elemzi az RTF dokumentumot, a SzövegáÁtalakító objek- 
tumot használja az átalakítás végrehajtására. Amikor az RTFOlvasó felismer egy RTF elemet 
( tokent") (sima szöveget vagy RTF-vezérlőszót), kiad egy kérést a SzövegÁtalakító objek- 
tumnak, hogy alakítsa át azt. A SzövegÁtalakító objektumok felelnek az adatátalakítás vég- 
rehajtásáért és az elem kért formátumban való megjelenítéséért is. 
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A SzövegáÁtalakító alosztályai különböző átalakításokra és formátumokra , szakosodhat- 
nak". Az ASCIIÁtalakító (ASCIIConverter) alosztály például figyelmen kívül hagyhat min- 
den kérelmet, kivéve a sima szöveges átalakításra vonatkozóakat. A TeXÁtalakító 
(TeXConverter) alosztályok azokat a műveleteket valósíthatják meg, amely a TeX formá- 
tumban való, a szöveg minden stílusinformációját tartalmazó szövegmegjelenítésre vonat- 
kozó kérelmekkel kapcsolatosak. A SzövegvVezérlőÁtalakító (TextWidgetConverter) alosz- 
tályok olyan összetett felhasználói felületi objektumokat hozhatnak létre, amelyek lehetővé 
teszik, hogy a felhasználó láthassa és szerkeszthesse a szöveget. 
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Mindegyik átalakítóosztály-típus tartalmazza, ami az összetett objektumok létrehozásához 
és összeállításához szükséges, és egy elvont felület mögé rejti azt. Az átalakító elkülönül az 
olvasóprogramtól, amely az RTF dokumentum elemzéséért felelős. 


Az Építő minta mindeme kapcsolatokat tartalmazza. A mintában az átalakító osztályok neve 
építő (builder), míg az olvasóprogramé irányító (director). A fenti példára alkalmazva: az Épí- 
tő minta elkülöníti a szöveges formátumot értelmező algoritmust (azaz az RTF formátumot 
elemző részt) az átalakított formátum létrehozásának és megjelenítésének módjától. Ez lehe- 
tővé teszi, hogy az RTFOlvasó elemző algoritmusát újra felhasználjuk RTF dokumentumok 
alapján készített másfajta szövegmegjelenítési formátumok létrehozására, és ehhez nem kell 
mást tenni, csak másik SzövegÁtalakító alosztályt megadni az RTFOlvasó osztálynak. 


Alkalmazhatóság 


Az Építő mintát a következő esetekben használjuk: 


s Az összetett objektumok létrehozási algoritmusának függetlennek kell lennie az ob- 
jektumot alkotó részegységektől és azok összeállítási módjától. 

e Az építés folyamatának lehetővé kell tennie, hogy a létrehozott objektum többféle- 
képpen jelenhessen meg. 
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Szerkezet 











for all objektum in szerkezet ( 
építő ÉpítRészt) 
ba 








Résztvevők 


e Építő CSzövegÁtalakító) 
-— Megadja a Termék objektumok alkotórészeinek létrehozására szolgáló elvont 
felületet. 
"  KonkrétÉpítő (ASCIIÁtalakító, TeXÁtalakító, SzövegvezérlőÁtalakító) 
— Az Építő felületét megvalósítva megalkotja és összeállítja a termék részeit. 
-— Meghatározza és nyilvántartja az általa létrehozott megjelenítési módokat. 
— A termék beolvasására szolgáló felületet (például SzerezASCIiISZöveg, SzerezSzö- 
vegVezérlő) biztosít. 
s Irányító (RTFOlvasó) 
— Az Építő felület segítségével megalkot egy objektumot. 
e Termék (ASCIISzöveg, TeXSzöveg, SzövegVezérlő) 
— A felépítendő összetett objektumot jelképezi. A KonkrétÉpítő felépíti a termék 
belső ábrázolását, és meghatározza a termék összeállítási folyamatát, 
— Tartalmazza az elemeket meghatározó osztályokat, köztük az elemek összeállítá- 
sára szolgáló felületeket is. 


Együttműködés 


" Az ügyfél létrehozza az Irányító objektumot, és beállítja a megfelelő Építő objektummal. 
e Az Irányító értesíti az építőt, ha a termékhez hozzá kell adni valamilyen alkotórészt. 
e Az Építő kezeli az irányítótól érkező kérelmeket, és alkotórészeket ad a termékhez. 

. Az ügyfél elkéri a terméket az építőtől. 


A következő együttműködési diagram azt szemlélteti, hogyan működik együtt az Építő és az 
Irányító az ügyféllel. 








egyÜgyfél egylrányító egyKonkrétÉpítő 





new KonkrétéÉpítő 





Felépít) 











SzerezEredményt) 




















Következmények 


Az Építő minta legfőbb előnyei a következők: 


1. Lehetővé teszi a termék belső ábrázolásának megváltoztatását. Az Építő objektum 
egy elvont felületet biztosít az irányító számára a termék összeállításához. A felület 
lehetővé teszi, hogy az építő elrejtse a termék belső szerkezetét, valamint a termék 
összeállításának módját is. Mivel a termék összeállítása egy elvont felületen át törté- 
nik, a termék belső ábrázolásának megváltoztatásához elegendő egy új építőt meg- 
határozni. 
dulrendszerű kialakítást, hogy egységbe zárja az összetett objektum összeállításának 
és megjelenítésének módját. Az ügyfélnek nem kell tudnia semmit a termék belső 
szerkezetét meghatározó osztályokról, így ilyen osztályok nem jelennek meg az Épí- 
tő felületében. 

Mindegyik KonkrétÉpítő tartalmazza az összes olyan kódot, amely egy adott termék- 
fajta létrehozásához és összeállításához szükséges. A kódot csak egyszer kell megírni, 
aztán a különböző Irányítók újra felhasználják azt a Termék különféle változatainak 
ugyanabból az elemhalmazból való felépítéséhez. A korábban említett RTF-es példá- 
ban például meghatározhatunk egy olvasóprogramot egy RTF-től eltérő formátum- 
hoz, mondjuk egy SGMLOlvasó (SGMLReader) alosztályt, majd ugyanazokat 
a SzövegÁtalakító alosztályokat felhasználva előállíthatjuk az SGML dokumentumok 
ASCIlSzöveg, TeXSzöveg és SzövegVezérlő alosztályok szerint formázott változatát is. 
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3. A létrehozási folyamat finomabb vezérlését teszi lehetővé. Azoktól a létrehozási min- 
táktól eltérően, amelyek egy lépésben alakítják ki a termékeket, az Építő minta az 
irányító felügyeletével lépésről lépésre alkotja meg azokat. Az irányító csak akkor 
veszi át a terméket az építőtől, amikor az már készen van. Emiatt az Építő felület job- 
ban tükrözi a termék megalkotásának folyamatát, mint a többi létrehozási minta, és 
így finomabban lehet vezérelni az építési folyamatot és ennek következtében a vég- 
eredményként kapott termék belső szerkezetét. 


Megvalósítás 


Jellemzően van egy elvont Építő osztály, amely meghatározza minden olyan összetevő mű- 
ködését, amelynek létrehozására az irányító megkéri. A műveletek alapértelmezés szerint 
nem tesznek semmit. A KonkrétÉpítő osztályok azon elemek esetében felülbírálják a műve- 
leteket, amelyeknek a létrehozásában érdekeltek. 


A megvalósítással kapcsolatban az alábbiakat kell figyelembe venni: 


1. Összeállítási és építési felület. Az Építők a termékeket lépésről lépésre alkotják meg, 
ezért az Építő osztály felületének eléggé általánosnak kell lennie ahhoz, hogy min- 
denféle konkrét építő számára lehetővé tegye a termékek létrehozását. 

A tervezés kulcsproblémája az építési és összeállítási modell. Azok a modellek általá- 
ban kielégítőek, ahol a létrehozási kérelmek eredményét egyszerűen hozzácsatolják 
a termékhez. A RTF-es példában az építő átalakítja a következő elemet, és hozzáfűzi 
az addig már átalakított szöveghez. 

Néha viszont hozzá kell férni a korábban felépített termék elemeihez. A Példakód 
részben lévő labirintusos példában a MazeBuilder (LabirintusÉpítő) felület lehetősé- 
get ad arra, hogy egy ajtót vegyünk fel két, már meglévő szoba közé. Az alulról felfe- 
lé építkező faszerkezetek — például az elemzőfák — egy másik példáját adják a prob- 
léma megoldására. Ebben az esetben az építő gyermekcsomópontokat ad vissza az 
irányítónak, amely aztán átadja azokat a szülőcsomópontokat kialakító építőnek. 

2. Miért nem elvont osztályokat használunk a termékekhez? Általános esetben a konk- 
rét építők által előállított termékek oly mértékben eltérnek megjelenésükben, hogy 
csak keveset nyerhetünk azzal, ha a különféle termékekhez ugyanazt az általános 
szülőosztályt rendeljük. Az RTF-es példában nem túl valószínű, hogy az ASCIISzöveg 
és a SzövegVezérlő objektum felülete közös lesz, és az sem, hogy szükségük legyen 
rá. Mivel az ügyfél általában a megfelelő konkrét építővel állítja be az irányítót, az 
ügyfél tudja, hogy az Építő mely konkrét alosztálya van használatban, és ennek meg- 
felelően tudja kezelni a termékeket. 

3. Üres függvények alapértelmezettként az Építőben. A Ct4 nyelvben az építő függvé- 
nyeket szándékosan nem tisztán virtuális tagfüggvényekként vezetjük be. Ehelyett 
üres függvényekként határozzuk meg őket, lehetővé téve, hogy az ügyfelek csak 
azokat a műveleteket bírálják felül, amelyekben érdekeltek. 
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Példakód 


A CreateMaze tagfüggvény egy olyan változatát fogjuk létrehozni, amely a MazeBuilder 
osztály egyik építőjét kapja arigumentumként. 


A MazeBuilder osztály a következő felületet határozza meg a labirintus létrehozásához: 


class MazeBuilder ( 
public: 
virtual void BuildMaze() ( ) 
virtual void BuildRoom(int room) ( ) 
virtual void BuildDoor(int roomFrom, int roomTo) ( ) 


virtual Mazer GetMaze() ( return 0; ) 
protected: 

MazeBuilder() ; 
b; 


Ez a felület három dolgot képes létrehozni: (1) a labirintust, (2) szobákat a megfelelő szo- 
baszámmal és (3) ajtókat a számozott szobák között. A GetMaze (SzerezLabirintus) műve- 
let a labirintust adja vissza az ügyfélnek. A MazeBuilder alosztályai felülbírálják ezt a mű- 
veletet, hogy a saját maguk által felépített labirintust adják vissza. 


A MazeBuilder összes labirintusépítő művelete alapértelmezés szerint nem csinál sem- 
mit. Nem tisztán virtuálisként vezetjük be őket, hogy a származtatott osztályok csak azokat 
a függvényeket bírálhassák felül, amelyekben érdekeltek. 


Ha adott a MazeBuilder felület, a CreateMaze tagfüggvényt úgy módosíthatjuk, hogy 
ezt az építőt vegye át paraméterként. 


Mazet MazeGame:  :CreateMaze (MazeBuilderg builder) ( 
builder.BuildMaze() ; 


builder.BuildRoom(1) ; 
builder.BuildRoom(2) ; 
builder.BuildDoor(1, 2); 


return builder.GetMaze() ; 
§ 


Hasonlítsuk össze a CreateMaze ezen változatát az eredetivel. Figyeljük meg, hogy az épí- 
tő hogyan rejti el a labirintus belső ábrázolását — azaz az ajtókat, szobákat és falakat megha- 
tározó osztályokat —, és hogyan állítja össze ezekből az elemekből a végleges labirintust. 
Biztos van, aki már rájött, hogy vannak olyan osztályok, amelyek a szobák és ajtók megjele- 
nítésére szolgálnak, de nyoma sincs a falak megjelenítésére valóknak. Ez megkönnyíti a la- 
birintus megjelenítési módjának megváltoztatását, mivel a MazeBuilder egyik ügyfelét 
sem kell megváltoztatni. 
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A többi létrehozási mintához hasonlóan az Építő minta is egységbe zárja az objektumok lét- 
rehozásának módját, amely ebben az esetben a MazeBuilder által meghatározott felüle- 
ten át történik. Ez annyit tesz, hogy a MazeBuilder felhasználható többféle labirintus fel- 
építésére. Nézzük meg ezt most a CreateComplexMaze (LétrehozÖsszetettLabirintus) 
művelettel: 


Mazet MazeGame: : reateComplexMaze (MazeBuilderg builder) ( 
builder.BuildRoom(1) ; 
77 
builder.BuildRoom(1001) ; 


return builder.GetMaze( ) ; 


Figyeljük meg, hogy a MazeBuilder nem magát a labirintust hozza létre, a fő célja csak 
annyi, hogy egy felületet határozzon meg a labirintusok létrehozásához. Üres megvalósítá- 
sokat határoz meg, főleg kényelmi szempontok miatt. A konkrét munkát a MazeBuilder 
alosztályai végzik. 


A StandardMazeBuilder (SzabványlabirintusÉpítő) alosztály egy olyan megvalósítás, 
amely egyszerű labirintusokat készít. A saját maga által készített labirintus adatait 
a currentMaze ( aktuálisLabirintus) változóban tárolja. 


class StandardMazeBuilder : public MazeBuilder ( 
public: 
StandardMazeBuilder ( ) ; 


virtual void BuildMaze() ; 
virtual void BuildRoom(int) ; 
virtual void BuildDoor(int, int); 


virtual Mazet GetMaze(); 

private: 
Direction CommonWall(Roomt, Roomt) ; 
Mazet  currentMaze; 


); 


A CommonWall (KözösFaD egy olyan segédművelet, amely meghatározza a szobák közti 
közös falak irányát. 


A StandardMazeBuilder konstruktor egyszerűen csak kezdőértéketada currentMaze 
változónak. 


StandardMazeBuilder : : 
.CurrentMaze z 0; 





tandardMazeBuilder () ( 
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A BuildMaze (Építlabirintus) példányosítja az egyik Maze osztályt, amelyet a többi műve- 
let állít össze, és végül visszaadja az ügyfélnek (a GetMaze művelettel). 


void StandardMazeBuilder: :BuildMaze () ( 
.CurrentMaze - new Maze; 


Mazet StandardMazeBuilder : : GetMaze () ( 
return . currentMaze; 
bi 


A BuildRoom (ÉpítSzoba) művelet egy szobát hoz létre, és felépíti a határoló falait: 


void StandardMazeBuilder: :BuildRoom (int n) ( 
if (! currentMaze-5RoomNo(n)) ( 
Roomt room - new Room(n); 
.currentMaze-5AddRoom( room) ; 


room-sSetSide(North, new Wall); 
room-sSetSide(South, new Wall) ; 
room-sSetSide(East, new Wall); 
room-sSetSide(West, new Wall); 


Ha ajtót szeretnénk két szoba közé, a StandardMazeBuilder megkeresi a két szobát 
a labirintusban, és a közös falukat: 


void StandardMazeBuilder: :BuildDoor (int nil, int n2) ( 
Roomt ri - . currentMaze-5RoomNo (n1 ) ; 
Roomt r2 - currentMaze-5RoomNo (n2) ; 
hoor" 4 new Dooríri, 2): 


r1-sSetSide(CommonWall(ri1,r2), d); 
r2-5sSetSide(CommonWall(r2,r1), d); 


Az ügyfelek most a CreateMaze műveletet és a StandardMazeBui Lder alosztályt együtt 
használva hozhatják létre a labirintust: 


MazeYr maze; 
MazeGame game; 
StandardMazeBuilder builder; 


game.CreateMaze(builder) ; 
maze - builder.GetMaze(); 
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Berakhattuk volna az összes StandardMazeBuilder műveletet a Maze osztályba, és 
hagyhattuk volna, hogy minden Maze osztály felépítse saját magát (azaz a labirintus). De 
ha kisebbre vesszük a Maze osztályt, könnyebb lesz megérteni és módosítani, és a Stan- 
dardMazeBuilder alosztályt könnyű elkülöníteni a Maze osztálytól. Ennél is fontosabb, 
hogy a kettőt elkülönítve sokféle MazeBuilder építőt használhatunk, amelyek mindegyi- 
ke különböző osztályokat használ a szobák, falak és ajtók létrehozására. 


Egy egzotikusabb MazeBuilder építő a CountingMazeBuilder (SzámolóLabirintus- 
Építő). Ez az építő nem hoz létre semmilyen labirintust, csak összeszámolja a különféle lét- 
rehozható összetevőket. 


class CountingMazeBuilder : public MazeBuilder ( 
public: 
CountingMazeBuilder ( ) ; 


virtual void BuildMaze(); 

virtual void BuildRoom(int) ; 

virtual void BuildDoor(int, int); 
virtual void AddWall(int, Direction); 


void GetCounts(intg, int§) const; 
private: 

int  doors; 

int . rooms; 


1; 


A konstruktor kezdőértéket ad a számlálóknak, amelyek értékét a felülbírált MazeBuilder 
műveletek növelik. 


CountingMazeBuilder : : CountingMazeBuilder () ( 
.-rooms - doors - 0; 


) 


void CountingMazeBuilder: :BuildRoom (int) ( 
.-rOOMS--4-; 


) 


void CountingMazeBuilder: :BuildDoor (int, int) ( 
.-doorstt; 
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void CountingMazeBuilder : :GetCounts ( 
inte rooms, intg doors 

) const ( 
rooms - . rooms; 
doors -  doors; 
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Egy ügyfél így alkalmazhatja például a CountingMazeBuilder alosztályt: 


int rooms, doors; 
MazeGame game; 
CountingMazeBuilder builder; 


game.CreateMaze(builder) ; 
builder.GetCounts(rooms, doors); 


cout cz "A labirintusban " 
cz rooms cz " szoba és " 
cz doors cc " ajtó van." cc endl; 


Ismert felhasználások 


Az RTF-átalakító alkalmazás az ET--t IWGM88] része. Szövegkialakító blokkja egy építőt 
használ az RTF formátumban tárolt szöveg feldolgozására. 


Az Építő a Smalltalk-80 [Par90] esetében általános minta: 


e A fordítói alrendszerben a Parser (Elemző) osztály egy olyan Irányító, amely egy 
ProgramNodeBuilder (ProgramCsomópontÉpítő) nevű objektumot kap argumen- 
tumként. A Parser objektumok értesítik saját ProgramNodeBuilder objektumukat, 
amikor felismernek egy nyelvtani szerkezetet. Miután az elemző végzett, elkéri az 
építőtől azt az elemzőfát, amelyet felépített, és visszaadja az ügyfélnek. 

e A ClassBuilder (OsztályÉpítő) olyan építő, amelyet az osztályok (Class) használnak 
arra, hogy alosztályokat hozzanak létre saját részükre. Ebben az esetben a Class egy- 
szerre Irányító és Termék. 

s A ByteCodeStream (BájtKkódFolyam) olyan építő, amely bájttömb formájában hoz 
létre egy lefordított metódust. A ByteCodeStream az Építő minta nem szabványos 
felhasználási módja, mert a létrehozott összetett objektum bájttömb formájában kó- 
dolt, nem normál Smalltalk objektumként. A ByteCodeStream felülete viszont olyan, 
mint az építőké általában, és a ByteCodeStream könnyen lecserélhető más olyan 
osztályokra, amelyek összetett objektumként jelenítik meg a programokat. 


Az Adaptive Communications Environment szolgáltatásbeállító keretrendszere (Service 
Configurator) egy építő segítségével alkotja meg a hálózati szolgáltatási összetevőket, ame- 
lyek futásidőben kapcsolódnak egy kiszolgálóhoz [SS94]. Az összetevőket valamilyen beál- 
lítási nyelv írja le, amely egy LALR(1) elemzővel elemezhető. A jelentéselemző eljárások 
azon az építőn hajtanak végre műveleteket, amely a szolgáltatási összetevőhöz ad hozzá in- 
formációkat. Ebben az esetben az elemző Irányító. 
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Kapcsolódó minták 


Az Elvont gyár annyiban hasonlít az Építőhöz, hogy az is összetett objektumok megalkotá- 
sára képes. A legfőbb eltérés közöttük, hogy az Építő minta az összetett objektumok lépés- 
ről lépésre történő létrehozását helyezi előtérbe, az Elvont gyár pedig a termékobjektum- 
családokra helyezi a hangsúlyt (egyenek azok egyszerűek vagy összetettek). Az Építő utol- 
só lépésként adja vissza a terméket, míg az Elvont gyár azonnal. 


Az építő gyakran Összetételeket készít (lásd az Összetétel tervezési mintáD). 


Gyártófüggvény 


Osztálylétrehozási minta 


Cél 


Felület meghatározása egy objektum létrehozásához, az alosztályokra bízva, melyik osz- 
tályt példányosítják. A gyártófüggvények megengedik az osztályoknak, hogy a példányosí- 
tást az alosztályokra ruházzák át. 


Egyéb nevek 


Factory Method, Gyár módszer, Gyártó metódus, Virtuális konstruktor 


Feladat 


A keretrendszerek elvont osztályokat használnak az objektumok közötti kapcsolatok meg- 
határozására és fenntartására. A keretrendszer gyakran felelős ezeknek az objektumoknak 
a létrehozásáért is. 


Képzeljünk el egy olyan alkalmazásokhoz való keretrendszert, amely több dokumentumot 
is meg tud jeleníteni a felhasználó számára. Ebben a keretrendszerben a két fő elem az Al- 
kalmazás (Application) és a Dokumentum (Document) osztály. Mindkét osztály elvont, és 
az ügyfeleknek alosztályt kell belőlük készíteni ahhoz, hogy elő tudják állítani ezen osztá- 
lyok alkalmazásfüggő megvalósításait. Egy rajzolóprogram létrehozásához például a Rajz- 
Alkalmazás (DrawingApplication) és a RajzDokumentum (DrawingDocument) osztályt ha- 
tározzuk meg. Az Alkalmazás osztály felel a dokumentumok kezeléséért, és ez hozza őket 
létre, amikor arra szükség van, azaz amikor a felhasználó egy menüben például a Megnyi- 
tás vagy az Új elemet választja. 
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Mivel az, hogy melyik Dokumentum alosztályból kell példányt létrehozni, alkalmazásfüg- 
gő, az Alkalmazás osztály nem tudja előre megjósolni, melyik Dokumentum alosztályt kell 
példányosítani — csak azt tudja, hogy mikor kell új dokumentumot létrehozni, azt nem, 
1ogy milyen típusút. Ez egy nagy problémát vet fel: a keretrendszernek példányokat kell 
előállítania az osztályokból, de csak az elvont osztályokat ismeri, amelyeket viszont nem 
tud példányosítani. 


Erre a problémára a Gyártófüggvény minta ajánlja a megoldást. A gyártófüggvény zárja egy- 
ségbe azt a tudást, hogy melyik Dokumentum alosztályt kell létrehozni, és kiemeli ezt a tu- 
dást a keretrendszerből. 



































doku kk 
Dokumentum ssiztisali 
Megnyit() LétrehozDokumantum() Dokumentum! dokumentum — LétrehozDokumentumí]; 
Bezár() ÚjDokumentumt) 0-h-----e e dokumentumok. Hozzásd dokumentum]; 
Ment) MegnyitDokumentum() -dokumentum-— Megnyit(); 
Visszaállít() 
SajátDokum.  [-a - - - - - - - - SajátAlkalmazás 

KR] 
nme mem 





Az Alkalmazás alosztályok az Alkalmazás osztályon működő elvont LétrehozDokumentum 
(CreateDocument) művelet felülírásával adják vissza a megfelelő Dokumentum alosztályt. 
Az Alkalmazás alosztály példányosítása után már képes példányosítani az alkalmazásfüggő 
dokumentumokat, anélkül, hogy tudná, melyik osztályba tartoznak. A LétrehozDoku- 
mentum műveletet gyártófüggvénynek (gyártó metódusnak) is nevezik, mert ez felel az ob- 


jektumok , legyártásáért". 


Alkalmazhatóság 


A Gyártófüggvény mintát az alábbi esetekben használjuk: 


e Az osztály nem tudja előre megjósolni, milyen objektumosztályt kell létrehoznia. 

s Az osztály azt szeretné elérni, hogy az alosztályai adják meg, milyen objektumot kell 
létrehozni. 

e Az osztályok átruházzák a felelősséget a számos segítő alosztály egyikére, és mi sze- 
retnénk tudni, melyik lett a képviselő. 
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Szerkezet 
Létrehozó 
Termék a 
GyártóFüggvény() vá 
EgyMűvelet) —— k-----.J termék s GytetFtggyényű 
a A 
KonkrétTermék  f47------- KonkrétLétrehozó 
GyártóFüggvény()  0-4--- - - - retum new KonkrétTermék S 
Résztvevők 


s Termék (Dokumentum) 

— Meghatározza a gyártófüggvény által létrehozott objektumok felületét. 
e  KonkrétTermék (SajátDokumentum) 

— Megvalósítja a Termék felületet. 
e Létrehozó (Alkalmazás) 

— Meghatározza azt a gyártófüggvényt, amely egy Termék (Product) típusú objektu- 
mot ad vissza. A Létrehozó (Creator) meghatározhatja a függvény valamilyen alap- 
értelmezett megvalósítását is, amely egy alapértelmezett KonkrétTermék objektu- 
mot ad vissza. 

— Meghívhatja a Termék objektumot létrehozó gyártófüggvényt. 

e  KonkrétLétrehozó (SajátAlkalmazás) 
— Felülbírálja a gyártófüggvényt, hogy a KonkrétTermék alosztály egy példányát ad- 


ja vissza. 
Együttműködés 


s A létrehozó a saját alosztályaira bízza a gyártófüggvény meghatározását, hogy az a meg- 
felelő KonkrétTermék alosztály egy példányát adja vissza. 


Következmények 





A gyártófüggvények kiküszöbölik az alkalmazásfüggő osztályok kódhoz kötésének szüksé- 
gességét. A kód csak a Termék felülettel foglalkozik, ezért képes együttműködni bármely 
felhasználó által meghatározott KonkrétTermék osztállyal. 





Gyártófüggvény 
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A gyártófüggvényekben rejlő hátrány az, hogy az ügyfeleknek esetleg a Létrehozó osztály- 
ból is alosztályt kell létrehozniuk egy adott KonkrétTermék objektum elkészítéséhez. Az al- 
osztály-származtatás abban az esetben megfelel, ha az ügyfélnek amúgy is alosztályt kelle- 
ne létrehoznia a Létrehozó osztályból, de a többi esetben az ügyfélnek ilyenkor egy másik 
kibontakozási ponttal is foglalkoznia kell. 


A Gyártófüggvény mintának többek között két előnye van: 


1. Horgokat biztosít az alosztályok számára. Ha egy osztályon belül gyártófügg- 

vénnyel hozunk létre objektumokat, az mindig rugalmasabb, mintha közvetlenül 
hoznánk létre azokat. A Gyártófüggvény minta egy olyan horoggal (hook) látja el az 
alosztályokat, amelynek segítségével létrehozható az objektum bővített változata. 
A dokumentumos példában a Dokumentum osztályban meghatározható egy Létre- 
hozrFájlPárbeszédablak (CreateFileDialog) nevű gyártófüggvény, amely egy alapér- 
telmezett párbeszédablak-objektumot hoz létre a meglévő dokumentumok megnyi- 
tásához. A Dokumentum alosztály ezt a függvényt felülbírálva határozhat meg egy 
alkalmazásfüggő párbeszédablakot. Ebben az esetben a gyártófüggvény nem elvont, 
hanem egy ésszerű alapértelmezett megvalósítást tesz lehetővé. 

2. Összekapcsolja a párhuzamos osztályhierarchiákat. Az eddig vizsgált példákban 
a gyártófüggvényt csak a Létrehozó osztályok hívták meg, de ennek nem kell okvet- 
lenül így lennie. Az ügyfelek is hasznosnak találhatják a gyártófüggvényeket, főleg 
párhuzamos osztályhierarchiák esetében. 

Párhuzamos osztályhierarchiák akkor jönnek létre, amikor egy osztály átadja felelőssé- 
gi körének egy részét egy másik, önálló osztálynak. Képzeljünk el egy olyan rajzot, 
ami interaktív módon módosítható, azaz nyújtható, áthelyezhető és elforgatható az 
egér segítségével. Ennek megvalósítása nem mindig könnyű, gyakran van hozzá szük- 
ség a módosítások egy adott időpontbeli állapotát tükröző adatok tárolására és frissíté- 
sére. Ezekre az állapotinformációkra csak a módosítások során van szükség, ezért nem 
kell azokat a rajzobjektumban tárolni. Ezenkívül a különböző rajzok módosításkor kü- 
lönbözőképpen viselkednek. Egy vonal nyújtása például okozhatja az egyik végpont 
áthelyezését, míg egy szöveges ábra nyújtásakor a sortávolság változhat. 

Ezek miatt a korlátozások miatt jobb külön Módosító (Manipulator) objektumot 
használni, amely megvalósítja az interaktivitást, és nyilvántartja a módosításhoz 
szükséges állapotinformációkat. A különféle ábrák különböző Módosító alosztályo- 
kat használhatnak az egyes műveletek kezelésére. Az így kapott Módosító osztályhi- 
erarchia (legalább részben) illeszkedik az Ábra (Figure) osztályhierarchiához: 
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Az Ábra osztály egy olyan LétrehozMódosító gyártófüggvényt biztosít, amely lehető- 
vé teszi, hogy az ügyfelek létrehozzák a megfelelő Módosító alosztályt. Az Ábra al- 
osztályok e függvényt felülbírálva adják vissza a Módosító alosztály egy olyan példá- 
nyát, amely számukra megfelelő. A másik lehetőség, hogy az Ábra osztály valósítja 
meg a LétrehozMódosító műveletet, úgy, hogy az egy alapértelmezett Módosító pél- 
dányt adjon vissza, és az Ábra alosztályok egyszerűen csak öröklik az alapértelme- 
zést. Az ezt végrehajtó Ábra osztályoknak nincs szükségük semmilyen megfelelő 
Módosító alosztályra, emiatt a hierarchiák csak részlegesen ,párhuzamosak". 
Figyeljük meg, hogy a gyártófüggvény hogyan határozza meg a két osztályhierarchia 
közötti kapcsolatot, meghatározva azt, hogy mely osztályok tudása tartozik együvé. 


Megvalósítás 


A Gyártófüggvény minta megvalósításakor legyünk tekintettel a következőkre: 


1. Két főbb változat létezik. A Gyártófüggvény mintának két főbb változata létezik: (1) 

az az eset, amikor a Létrehozó elvont osztály, és nem biztosítja az általa meghatáro- 
zott gyártófüggvény semmilyen megvalósítását, és (2) az az eset, amikor a Létrehozó 
konkrét osztály, és biztosítja a gyártófüggvény egy alapértelmezett megvalósítását. 
Az is lehetséges, hogy egy olyan elvont osztályunk legyen, amely meghatároz vala- 
milyen alapértelmezett megvalósítást, de ez nem túl gyakori. 
Az első esetben az alosztályok kötelezőek a megvalósítás meghatározásához, mert 
nincs semmilyen elfogadható alapértelmezés. Ez azt a problémát veti fel, hogy előre 
nem látható alosztályokat kell példányosítani. A második esetben a konkrét Létreho- 
zó a gyártófüggvényt elsősorban a rugalmassága miatt veszi igénybe. A szabály a kö- 
vetkező: ,Az objektumokat külön művelettel hozzuk létre, hogy az alosztályok felül 
tudják bírálni a létrehozásuk módját." Ez a szabály biztosítja, hogy az alosztályterve- 
zők szükség esetén módosíthassák azokat az objektumosztályokat, amelyeket a szü- 
lőosztályaik példányosítanak. 


Gyártófüggvény 
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2. Paraméterezett gyártófüggvények. A minta egy másik változata lehetőséget ad arra, 


hogy a gyártófüggvény többféle terméket hozzon létre. A függvény ekkor egy olyan 
paramétert kap, amely azonosítja a létrehozandó objektumtípust. A függvény által 
készített minden objektum közösen a Termék felületet használja. A dokumentumos 
példában az alkalmazás többféle dokumentum használatát megengedheti; ehhez 
a LétrehozDokumentum műveletnek átadunk még egy paramétert, amely megadja, 
milyen típusú dokumentumot kell létrehozni. 
A Unidraw grafikus szerkesztő keretrendszer ÍVL90] ezt a megközelítést használja 
a lemezre mentett objektumok újraalkotására. Egy Creatór nevű osztályt találunk 
benne, a Create gyártófüggvénnyel, amely egy osztályazonosítót kap argumentum- 
ként. Az osztályazonosító adja meg, melyik osztályt kell példányosítani. Amikor 
a Unidraw lemezre ment egy objektumot, először az osztályazonosítót írja ki, majd 
a példányváltozókat. Amikor újraalkotja az objektumot a lemezről, az osztályazono- 
sítót olvassa be először. 
Az osztályazonosító beolvasása után a keretrendszer meghívja a Create gyártófügg- 
vényt, és átadja neki paraméterként az azonosítót. A Create megkeresi a megfelelő 
osztályhoz tartozó konstruktort, és azt használja az objektumpéldány létrehozására. 
Végül a Create meghívja az objektum Read (Olvas) műveletét, amely beolvassa 
a lemezről az objektum többi adatát, és előkészíti az objektum példányváltozóit. 
A paraméterezett gyártófüggvény általános formája a következő: (A MyProduct és 
a YourProduct a Product osztály alosztályai.) 

class Creator ( 

public: 

virtual Productt Create(ProductId) ; 


); 

Productt Creator::Create (ProductId id) ( 
if (id -- MINE) return new MyProduct; 
if (id -- YOURS) return new YourProduct; 


//a többi termék esetében ismétlődik... 


return 0; 


) 


A paraméterezett gyártófüggvény felülbírálása a Létrehozó (Creator) által előállított 
termékek egyszerű bővítését és módosítását teszi lehetővé. Az új termékfajtákhoz új 
azonosítókat lehet bevezetni, illetve más termékekhez társíthatjuk a már meglévő 
azonosítókat. 
A MyCreator (SajátLétrehozó) alosztály segítségével felcserélhető például a My- 
Product (EnyémTermék) és a YourProduct (TiédTermék) alosztály, és támogatható 
egy új TheirProduct (ÖvékTermék) alosztály: 
Product? MyCreator::Create (ProductId id) ( 
if (id -- YOURS) return new MyProduct; 
if (id -- MINE) return new YourProduct; 
//Megjegyzés: a YOURS (tiéd) és a MINE (enyém) megcserélése 
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if (id -- THEIRS) return new TheirProduct; 


return Creator: :Create(id) ; 
//ezt akkor hívja meg a program, ha a többi meghiúsul 
J 


Figyeljük meg, hogy ez a művelet az utolsó lépésben meghívja a Create-et a szülő- 
osztályra. Ennek oka, hogy a MyCreator : : Create csak a YOURS, MINE és THEIRS 
osztályokat kezeli másképpen, mint a szülőosztály. Más osztályokban nincs érde- 
keltsége. Emiatt a MyCreator alosztály kibővíti a létrehozott termékfajtákat, és kevés 
kivétellel az összes termék létrehozásának felelősségét átruházza saját szülőjére. 


. Nyelyfüggő változatok és problémák. A különböző nyelvek további érdekes változa- 


tok használatát teszik lehetővé, és további hibalehetőségeket rejtenek. 
A Smalltalk programok gyakran használnak olyan függvényt (metódust), amely 
visszaadja a példányosítandó objektum osztályát. A létrehozó gyártófüggvény ezt az 
értéket egy termék létrehozásához használhatja, tárolását vagy akár a kiszámítását 
pedig egy KonkrétLétrehozó alosztály vállalhatja. Az eredmény: még későbbi kötés 
a példányosítandó KonkrétTermék alosztálytípushoz. 
A dokumentumos példa Smalltalk nyelven írt változatában meghatározható egy 
documentClass (dokumentumOsztály) metódus az Application osztályra. A do- 
cumentClass a megfelelő Document osztályt adja vissza a dokumentumok példá- 
nyosításához. A documentClass metódusnak a MyApplication alosztályban törté- 
nő megvalósítása a MyDocument osztályt adja vissza. Így az Application osztályban 
a következők vannak: 

eclientMethod 

document :- self documentClass new. 


documentClass 
self subclassResponsibility 


A MyApplication osztályban pedig ezek: 

documentClass 

" MyDocument 

Ez az Application osztályhoz példányosítandó MyDocument osztályt adja vissza. 
Egy még rugalmasabb, a paraméterezett gyártófüggvényekhez hasonló megközelí- 
tés, ha a létrehozandó osztályt az Application osztály osztályváltozójaként tárol- 
juk. Ily módon a termék különböző változatainak előállításához nem kell alosztályo- 
kat létrehozni az Application osztályhoz. 
A Ct4 nyelvben a gyártófüggvények mindig virtuális függvények, és gyakran tisztán 
virtuálisak. Csak arra vigyázzunk, hogy ne hívjunk meg gyártófüggvényt a Létrehozó 
konstruktorában — a KonkrétLétrehozó alosztályban ugyanis ekkor még nincs jelen. 
Ezt úgy kerülhetjük el, ha ügyelünk arra, hogy a termékeket kizárólag olyan elérési 
műveletekkel próbáljuk meg elérni, amelyek igény esetén hozzák létre a terméket. 
A konkrét termék konstruktorban való létrehozása helyett a konstruktor csak 0 kez- 
dőértéket ad. Az elérési művelet visszaadja a terméket, de előbb ellenőrzi, hogy csak- 
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ugyan létezik-e, és ha nem, akkor létrehozza. Ezt a módszert néha lusta előkészítésnek 
(azy initialization) is nevezik. A következő kód egy jellegzetes megvalósítást mutat: 
class Creator ( 


public: 

Product$t GetProduct ( ) ; 
protected: 

virtual Productt CreateProduct ( ) ; 
private: 


Productt product; 
); 


Product! Creator ::GetProduct () ( 
if ( product sz 0) ( 
.product - CreateProduct-(); 
) 
return product; 


) 


Sablonok használata az alosztálykészítés elkerülése érdekében. Amint már említettük, 
a gyártófüggvényekben rejlő másik lehetséges buktató az, hogy időnként csak azért 
kell alosztályokat előállítanunk, hogy létrehozhassuk a megfelelő termékobjektumo- 
kat. A Cst nyelvben ez úgy kerülhető meg, ha a Létrehozó (Creator) osztályból sab- 
lonalosztályt hozunk létre, amely a Termék (Product) osztályt kapja paraméterként: 

class Creator ( 

public: 

virtual Product!" CreateProduct() - 0; 
) 


template cclass TheProducts5 
class StandardCreator: public Creator ( 
public: 
virtual Productt CreateProduct ( ) ; 
b 83 


template cclass TheProduct5 
Productt StandardCreatorcTheProduct:: : reateProduct () ( 
return new TheProduct; 


Ezt a sablont használva az ügyfél csak a termékosztályt , szállítja", ezért nincs szük- 
ség arra, hogy alosztályokat hozzunk létre a létrehozó osztályhoz. 
class MyProduct : public Product ( 
public: 
MyProduct ( ) ; 
éY 34 
1); 


StandardCreatorcMyProducts myCreator; 


114 3. fejezet " Létrehozási minták 





5. Névadási szabályok. Jó ötlet, ha olyan névadási szabályokat használunk, amelyek 
egyértelművé teszik, hogy gyártófüggvényekről van szó. Például a MacApp 
Macintosh alkalmazási keretrendszer (App89] azt az elvont műveletet, amely megha- 
tározza a gyártófüggvényt, Class" DoMakeClass() formában vezeti be, ahol 
a Class a Termék osztály. 


Példakód 


A korábban már látott CreateMaze függvény egy labirintust hoz létre és ad vissza. Ezzel 
a függvénnyel az az egyik gond, hogy mereven kódolja a labirintus, a szobák, az ajtók és 
a falak osztályait. A gyártófüggvényeket azért vezetjük be, hogy az alosztályok választhas- 
sák ki ezeket az elemeket. 


Először határozzuk meg a MazeGame labirintus, szoba, fal és ajtó objektumait létrehozó 
függvényeket: 


class MazeGame ( 
public: 
Mazetr CreateMaze( ) ; 


// gyártófüggvények 


virtual Mazet MakeMaze() const 
( return new Maze; ) 

virtual Roomy MakeRoom(int n) const 
( return new Room(n); ) 

virtual Wally MakeWall() const 
( return new Wall; ) 

virtual Doort MakeDoor(Roomt ri, Roomt r2) const 
( return new Door(ri, r2); ) 

); 


Mindegyik gyártófüggvény egy adott típusú labirintuselemet ad vissza. A MazeGame osztály 
olyan alapértelmezett megvalósításokat biztosít, amelyek a legegyszerűbb típusú labirintu- 
sokat, szobákat, falakat és ajtókat adják vissza. 


Most újraírhatjuk a CreateMaze osztályt úgy, hogy ezeket a gyártófüggvényeket használja: 


Mazet MazeGame: :CreateMaze () ( 
Mazet aMaze - MakeMaze( ) ; 


Roomt ri - MakeRoom(1); 
Roomt r2 - MakeRoom(2); 
Door" theDoor - MakeDoor(ri, r2); 
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aMaze-sAddRoom(r1) ; 
aMaze-5AddRoom(r2 ) ; 


r1l-5SetSide(North, MakewWwaltl ()); 
r1-sSetSide(East, theDoor); 
r1-sSetSide(South, MakeWall()); 
r1-sSetSide(West, MakeWall()); 


r2-sSetSide(North, MakeWall()); 
r2-5SetSide(East, MakeWallt(( ) ) ; 
r2-sSetSide(South, MakeWall()) ; 
r2-bSetSide(West, theDoor); 


return aMaze; 


) 


A különféle játékok alosztályokat hozhatnak létre a MazeGame osztályhoz a labirintus ele- 
meinek megadása érdekében. Ezek az alosztályok aztán felülbírálhatják a gyártófüggvé- 
nyek egy részét vagy akár az összeset úgy, hogy azok a termék különféle változatait adják 
vissza. A BompedMazeGame alosztály például olyan új meghatározásokat adhat a Room és 
a Wall termékeknek, hogy azok a bombarobbanás utáni változatokat adják vissza: 


class BombedMazeGame : public MazeGame ( 
public: 
BombedMazeGame ( ) ; 


virtual Wall: MakeWall() const 
( return new BombedWall; ) 


virtual Roomt MakeRoom(int n) const 
( return new RoomWithABomb(n); ) 
); 


Az EnchantedMazeGame változat valahogy így határozható meg: 


class EnchantedMazeGame : public MazeGame ( 
public: 
EnchantedMazeGame ( ) ; 


virtual Roomt MakeRoom(int n) const 
( return new EnchantedRoom(n, CastSpell()); ) 


virtual Door: MakeDoor(Roomt ri, Roomt r2) const 
( réturn new DoorNeedingSpellí(ri, r2); ) 
protected: 
Spell" CastSpell() const; 
hi; 
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Ismert felhasználások 


A gyártófüggvények meglehetősen elterjedtek az elemkészletekben és a keretrendszerek- 
ben. A korábban említett dokumentumos példa egy jellegzetes felhasználási mód a MacApp 
és az ET4-t IWGM88] rendszerekben. A módosítós példa a Unidrawból származik. 


A Smalltalk-80 Model/View/Controller (modell-nézet-vezérlő) keretrendszerének Class 
View COsztálynézeD nézetében egy defaultController (alapértelmezettVezérlő) nevű osz- 
tályt találunk, amely egy vezérlőt hoz létre, és ez gyártófüggvénynek is tűnhet [Par90], de 
a View osztály alosztályai megadják saját alapértelmezett vezérlőjük osztályát azáltal, hogy 
meghatározzák a defaultControllerClass osztályt, amely azt az osztályt adja vissza, amelyből 
a defaultController példányokat készít. Így tehát valójában a defaultControllerClass az igazi 
gyártófüggvény, tehát az alosztályoknak azt kell felülbírálniuk. 


A Smalltalk-80 nyelvben egy sokkal misztikusabb példa a Behavior (Viselkedés) osztály (az 
osztályokat jelképező összes objektumot tartalmazó főosztály) által meghatározott parser- 
Class (elemzőOsztály) gyártófüggvény (gyártó metódus), amely lehetővé teszi, hogy az osz- 
tályok testreszabott elemzőprogramot használjanak a forráskódhoz, Egy ügyfél meghatároz- 
hat például egy SOLParser (SOLElemező) osztályt egy beágyazott SOL-utasításokat tartalma- 
zó osztály forráskódjának elemzéséhez. A Behavior osztály a parserClass megvalósításával 
a szabványos Smalltalk Parser osztályt adja vissza. A beágyazott SOL-utasításokat tartalmazó 
osztály ezt a metódust bírálja felül (mint osztálymetódust), és az SOLParser osztályt adja 
vissza. 


Az IONA Technologies [ION94] cég Orbix ORB rendszere a Gyártófüggvény minta segítsé- 
gével hoz létre megfelelő típusú helyettest (lásd a Helyettes tervezési mintán), amikor egy 
objektum egy távoli objektumra mutató hivatkozást kér. A Gyártófüggvény minta meg- 
könnyíti az alapértelmezett helyettes lecserélését például egy olyanra, amely felhasználó 
oldali gyorstárat használ. 


Kapcsolódó minták 


Az Elvont gyár mintát gyakran gyártófüggvényekkel valósítják meg. Az Elvont gyár minta 
Feladat részében említett példa szintén egy gyártófüggvényt szemléltet. 


A gyártófüggvényeket általában sablonfüggvényekben hívják meg. A fentebb említett do- 
kumentumos példában az ÚjDokumentum (NewDocument) is ilyen sablonfüggvény. 


A prototípusok nem igénylik, hogy alosztályokat hozzunk létre a Létrehozó osztályból, de 
gyakran szükségük van egy, a Termék osztályon végrehajtott Előkészít (Initialize) művelet- 
re. A Létrehozó osztály az Előkészít művelet segítségével készíti elő az objektumot. A gyár- 
tófüggvényeknek nincs szükségük ilyen műveletre. 
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Prototípus 


Objektum-létrehozási minta 
Cél 


Prototípus példány használatával meghatározni, milyen típusú objektumokat kell létrehoz- 
ni, az új objektumokat pedig ennek a prototípusnak a lemásolásával előállítani. 


Feladat 


Kottaszerkesztő programot szeretnénk készíteni, átszabva egy képszerkesztőkhöz való ál- 
talános keretrendszert, és hangjegyeket, szünetjeleket, illetve kottavonalakat jelképező új 
objektumokat adva ahhoz. A szerkesztő keretrendszerhez egy olyan eszközpaletta fog tar- 
tozni, amelynek segítségével ezeket a zenei objektumokat felvehetjük a kottába. A palettán 
lehetnek még a zenei objektumok kijelölésére, áthelyezésére és más módon történő módo- 
sítására szolgáló eszközök is. Ha a felhasználó negyed hangjegyeket akar felvenni a kottá- 
ba, a negyed hang eszközre" kattint, és azt használja. Ha a hangjegyet felfelé vagy lefelé 
szeretné mozgatni a kotta ötvonalas rendszerében, megváltoztatva a hangmagasságát, arra 
az ,áthelyezés eszköz" használható. 





Tételezzük fel, hogy a keretrendszer biztosít egy elvont Grafika (Graphics) osztályt a grafi- 
kus összetevőkhöz, amilyenek a hangjegyek és a kottavonalak, valamint egy elvont Eszköz 
(Tool) osztályt a palettán lévő eszközök meghatározásához. Ezenkívül készen biztosítja 
a GrafikusEszköz (GraphicTool) alosztályt a grafikus objektumok példányait előállító és 
azokat a dokumentumhoz adó eszközökhöz. 


A GrafikusEszköz osztály azonban gondot jelent a keretrendszer-tervezőnek. A hangjegyek 
és kottavonalak osztályai csak erre az alkalmazásra jellemzőek, de a GrafikusEszköz osztály 
a keretrendszerhez tartozik. A GrafikusEszköz nem tudja, hogyan hozzon létre példányokat 
a zenei osztályokból, és hogyan adja azokat a kottához. Persze származtathatnánk alosztályo- 
kat a GrafikusEszköz osztályból a zenei objektumok különféle típusaihoz, de ekkor nagyon 
sok alosztály jönne létre, amelyek csak az általuk példányosított zenei objektumok típusában 
térnének el egymástól. Azt már tudjuk, hogy az objektum-összetétel az alosztálykészítés ru- 
galmas alternatívája. A kérdés csak az, hogyan tudja ezt a keretrendszer a GrafikusEszköz 
osztály példányainak azon Grafika osztállyal való paraméterezésére használni, amelynek 
a létrehozására szolgálnak. 


A megoldás: új Grafika osztály készíttetése a GrafikusEszköz osztállyal, lemásolva vagy 
,klónoözva" egy Grafika alosztály egy példányát. Ezt a példányt hívjuk prototípusnak. 
A GrafikusEszköz osztály azt a prototípust kapja paraméterként, amelyet klónoznia kell, és 
a dokumentumhoz kell adnia. Ha minden Grafika alosztály támogatja a Klónoz (Clone) mű- 
veletet, akkor a GrafikusEszköz osztály a Grafika osztály bármely típusát képes klónozni. 
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Kottaszerkesztőnkben tehát minden zeneiobjektum-készítő eszköz a GrafikusEszköz osz- 
tály egy példánya, amelyet különböző prototípusokkal készítünk elő. Mindegyik Grafikus- 
Eszköz példány egy zenei objektumot hoz létre, mégpedig úgy, hogy klónozza saját proto- 
típusát, majd felveszi a klónt a kottába. 
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A Prototípus mintát az osztályok számának további csökkentésére használhatjuk. Külön 
osztályok vannak az egész és a fél hangjegyekhez, de erre valószínűleg nincs szükség, ehe- 
lyett lehetnek ezek ugyanannak az osztálynak a különféle bitképekkel és időtartamokkal 
előkészített példányai. Az egész hangjegyek létrehozására szolgáló eszköz így egy olyan 
GrafikusEszköz osztály lesz, amelynek prototípusa egy olyan HangJegy (MusicalNote) osz- 
tály, amely úgy van előkészítve, hogy egész hanggá váljon. Ez rendkívüli mértékben csök- 
kentheti a rendszerben használt osztályok számát, és megkönnyíti új hangjegytípusok fel- 
vételét is a programba. 














Alkalmazhatóság 


A Prototípus mintát akkor használjuk, amikor a rendszernek függetlennek kell lennie a ter- 
mékek létrehozásának, összeállításának és megjelenítésének módjától, és 


" amikor a példányosítandó osztályokat futásidőben adják meg, például dinamikus 
betöltés útján, vagy 

" ha el szeretnénk kerülni a termékekével párhuzamos osztályhierarchiájú gyárak épí- 
tését, vagy 

" amikor egy osztály példányainak csak néhány különböző állapotkombinációja jö- 
het létre. Kényelmesebb lehet a megfelelő számú prototípust beépíteni, majd 
klónozni, mint egyenként példányosítani az osztályokat, minden alkalommal 


a megfelelő állapottal. 
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Szerkezet 
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s  Prototípus (Grafika) 
— Felületet vezet be önmaga klónozásához. 

e  KonkrétPrototípus (Kottavonal, EgészHang, FélHang) 
— Megvalósít egy műveletet önmaga klónozása érdekében. 
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— Új objektumot hoz létre, megkérve egy prototípust, hogy klónozza önmagát. 


Együttműködés 


e Az ügyfél megkéri az egyik prototípust, hogy klónozza önmagát. 


Következmények 


A Prototípus minta alkalmazása hasonló következményekkel jár, mint az Elvont gyáré vagy 
az Építőé: elrejti a konkrét termékosztályt az ügyfél elől, csökkentve ezzel azon nevek szá- 
mát, amelyeket az ügyfél ismer. Ezenkívül ezek a minták lehetővé teszik azt, hogy az ügyfél 


módosítás nélkül használja az alkalmazásra jellemző osztályokat. 


A Prototípus minta további előnyei: 


1. Termékek hozzáadása és eltávolítása futásidőben. A prototípusok lehetőséget ad- 
nak arra, hogy új konkrét termékosztályt építsünk be a rendszerbe, és ehhez nem 
kell mást tenni, csak bejegyeztetni egy prototípuspéldányt az ügyféllel. Ez némileg 
rugalmasabb, mint a többi létrehozási minta megoldása, mivel az ügyfél futásidőben 


építheti be és távolíthatja el a prototípusokat. 


120 


3. fejezet " Létrehozási minták 





2. Új objektumok megadása az értékek megváltoztatásával. A nagymértékben dinami- 


4. 


kus rendszerek lehetővé teszik, hogy objektum-összetételen keresztül — például ér- 
tékeket adva az objektum változóinak — határozzunk meg új viselkedésmódokat, 
nem új osztályokat meghatározva. Ekkor tulajdonképpen a meglevő osztályok pél- 
dányosításával, majd a példányokat ügyfélobjektum-prototípusokként bejegyezve 
határozunk meg új objektumtípusokat. Az ügyfél a prototípusra felelősséget átruház- 
va állíthat elő új viselkedésmódot. 

Ez a tervezési mód lehetőséget ad arra, hogy a felhasználók programozás nélkül hatá- 
rozzanak meg új , osztályokat". Valójában a prototípusok klónozása hasonló az osztá- 
lyok példányosításához. A Prototípus minta nagymértékben csökkentheti a rendszer 
által igényelt osztályok számát. A kottaszerkesztős példában a GrafikusEszköz osztály 
a zenei objektumok korlátlan változatosságát képes létrehozni. 

Új objektumok megadása a szerkezet megváltoztatásával. Sok alkalmazás elemek- 
ből és elemrészekből építi fel az objektumokat. Az áramkörtervező programok pél- 
dául részáramkörökből állítják össze az áramköröket". Az ilyen alkalmazások ké- 
nyelmi szempontok miatt gyakran lehetővé teszik összetett, felhasználó által megha- 
tározott szerkezetek példányosítását, mondjuk azért, hogy egy részáramkört több- 
ször is fel lehessen használni. 

A Prototípus minta ezt a megoldást is támogatja. A részáramkört egyszerűen csak 
hozzáadjuk prototípusként a különféle áramköri elemek választékához. Amennyi- 
ben az összetett áramköri objektumok a klónozás megvalósításakor mélymásolást 
végeznek (azaz az objektum minden alszerkezetét tartalmazó másolatot készítenek), 
a különféle felépítésű áramkörök prototípusokká válhatnak. 

Kevesebb alosztályra van szükség. A Gyártófüggvény minta gyakran a termékosztály 
hierarchiájával párhuzamos Létrehozó osztályhierarchiát hoz létre. A Prototípus min- 
ta lehetőséget ad a prototípusok klónozására, ahelyett, hogy egy gyártófüggvényt 
kérne meg arra, hogy új objektumot hozzon létre, emiatt a Létrehozó osztályhierar- 
chiára egyáltalán nincs is szükség. Ez elsősorban a C-t nyelvhez hasonló nyelveknél 
jelent előnyt, amelyek nem első osztályú objektumokként kezelik az osztályokat. 
Azon nyelvek esetében, amelyek viszont igen — ilyen például a Smalltalk és az 
Objective C -, kevesebb haszon származik ebből, mivel az osztályobjektumok min- 
dig használhatók létrehozóként. Az osztályobjektumok ezekben a nyelvekben már 
önmagukban prototípusokként viselkednek. 

Az alkalmazás dinamikus beállítása osztályokkal. Egyes futásidejű környezetek le- 
hetővé teszik az osztályok dinamikus betöltését az alkalmazásokba. A Prototípus 
minta kulcsszerepet tölthet be ezen képességek kiaknázásában a C-t és az ahhoz 
hasonló nyelvekben. 

Azok az alkalmazások, amelyek egy dinamikusan betöltött osztály példányait szeret- 
nék létrehozni, nem képesek statikusan hivatkozni annak konstruktorára, ehelyett 
a futásidejű környezet hoz létre automatikusan egy példányt minden osztályból, 
amikor az betöltődik, és bejegyzi a példányt egy prototípus-kezelőben (lásd a Meg- 





" Az ilyen alkalmazások az Összetétel, illetve a Díszítő mintát követik. 
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valósítás részt). Ezután az alkalmazás elkérheti a prototípus-kezelőtől az újonnan be- 
töltött osztályok példányait, olyan osztályokét, amelyeket eredetileg nem voltak 
a programba szerkesztve. Az ETt-- alkalmazás-keretrendszer IWGM88] futásidejű 
rendszere ezt a sémát használja. 


A Prototípus minta legfőbb felelőssége, hogy minden egyes Prototípus alosztály megvaló- 
sítsa a Klónoz műveletet, ami nem mindig egyszerű. Nehéz például megírni a műveletet 
olyankor, ha a kérdéses osztályok már léteznek, de megvalósítása akkor is nehéz lehet, ha 
olyan objektum van bennük, amely nem támogatja a másolást, vagy körkörös hivatkozáso- 
kat tartalmaznak. 


Megvalósítás 


A Prototípus minta különösen a statikus nyelveknél hasznos, amilyen például a C-t, ahol 
az osztályok nem objektumok, és futásidőben kevés vagy semmilyen típusinformáció nem 
áll rendelkezésre. Az olyan nyelveknél, mint a Smalltalk vagy az Objective C, amelyek 
a prototípusokkal egyenértékű objektumokat (azaz osztályobjektumokat) biztosítanak az 
osztályok példányainak létrehozásához, kisebb a jelentősége. A mintát a prototípusokra 
épülő nyelvek — amilyen a Self [US87] —, amelyekben minden objektumlétrehozás egy pro- 
totípus klónozása útján valósul meg, beépítve tartalmazzák. 


A prototípusok megvalósítása során tartsuk szem előtt a következőket: 


1. Prototípus-kezelő használata. Amikor egy rendszerben nincs rögzítve a prototípu- 

sok száma (azaz dinamikusan lehet őket létrehozni és megsemmisíteni), a rendelke- 
zésre álló prototípusokról nyilvántartást kell vezetni. Az ügyfelek maguk nem keze- 
lik a prototípusokat, csak a nyilvántartóba mentik azokat, és beolvassák onnan. 
Az ügyfél elkéri a nyilvántartóból a prototípust, mielőtt klónozná. Ezt a nyilvántartót 
nevezzük prototípus-kezelőnek. 
A prototípus-kezelő egy társításos tároló (asszociatív tár), amely egy adott kulcshoz 
tartozó prototípust ad vissza. Vannak benne műveletek a prototípusok kulcsokhoz 
történő bejegyzésére és a bejegyzés törlésére. Az ügyfelek futásidőben módosíthat- 
ják a nyilvántartót, illetve tallózhatnak is abban. Ez lehetővé teszi az ügyfelek számá- 
ra, hogy kódírás nélkül felvegyék a rendszer leltárát. 

2. A Klónoz művelet megvalósítása. A Prototípus minta legnehezebb része a Klónoz 
művelet helyes megvalósítása. Különösen trükkös olyankor, amikor az objektum- 
szerkezetek körkörös hivatkozásokat tartalmaznak. 

A legtöbb nyelv támogatja valamennyire az objektumklónozást. A Smalltalk például 
a copy művelet egy megvalósítását biztosítja ehhez, amelyet aztán az Object (Objek- 
tum) osztály minden alosztálya örököl. A C-4-- egy másoló konstruktort tartalmaz. 
Ezek a lehetőségek azonban nem oldják meg a , sekély másolat vagy mélymásolat" 
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problémát IGR83], azaz hogy az objektum klónozásakor valóban másolat készül-e 
a példányváltozókról, vagy csak meg lesznek osztva a klónozás után az eredeti pél- 
dány változói. 

A sekély" másolat készítése egyszerű és gyakran elegendő is, ezt csinálja alapértel- 
mezés szerint a Smalltalk. A C--t alapértelmezett másoló konstruktora tagszerű má- 
solást végez, ami azt jelenti, hogy a mutatók meg lesznek osztva a másolat és az ere- 
deti között. Az összetett felépítésű prototípusok klónozása során azonban általában 
mélymásolat készítésére van szükség, mivel a klónnak és az eredeti példánynak egy- 
mástól függetlennek kell lennie. Ezért biztosítani kell, hogy a klón elemei a prototí- 
pus elemeinek klónjai legyenek. A klónozás rákényszerít minket, hogy eldöntsük, 
mit akarunk megosztva használni, már ha egyáltalán van ilyen. 

Ha a rendszerben lévő objektumokhoz tartozik Ment (Save) és Betölt (Load) műve- 
let, akkor használhatók azok a Klónoz alapértelmezett megvalósításának előállításá- 
ra, ehhez nem is kell mást tenni, csak menteni az objektumot, majd azonnal újra be- 
tölteni. A Ment művelet egy memóriatárba menti az objektumot, a Betölt pedig má- 
solatot készít belőle, újra előállítva az objektumot a tárból, 

3. A klónok előkészítése. Miközben egyes ügyfelek tökéletesen elégedettek a klónnal 

úgy, ahogy az van, mások általuk választott kezdőértékekkel akarják ellátni annak 
néhány vagy az összes belső állapotát. Ezeket az értékeket a klónozási művelettel ál- 
talában nem lehet átadni, mert a számuk prototípus-osztályonként változó. Egyes 
prototípusoknak több előkészítő paraméterre is szükségük lehet, másoknak egyre 
sincs. A Klónoz művelet során történő paraméterátadás eleve kizárná egy egységes 
klónozó felület használatának lehetőségét. 
Az is megeshet, hogy a használandó prototípus-osztályok már előre meghatároznak 
bizonyos műveleteket az állapot kulcsértékeinek be- vagy alaphelyzetbe állításához. 
Ha ez a helyzet, az ügyfelek ezeket a műveleteket a klónozás megtörténte után 
azonnal használhatják, egyéb esetben viszont esetleg nekünk kell bevezetni az 
Initialize (Előkészíd műveletet (lásd a Példakód rész0), amely az előkészítő para- 
métereket kapja argumentumként, és azok alapján beállítja a klón belső állapotát. Vi- 
gyázzunk, hogy a klónozó műveletekből ne készítsünk mélymásolatokat — ezeket 
ugyanis esetleg törölni kell (akár kifejezetten, akár az Initialize műveleten belül), 
mielőtt újra előkészíthetnénk őket. 






Példakód 


A korábban már látott MazeFactory osztály MazePrototypeFactory (LabirintusProto- 
típusGyár) alosztályát fogjuk létrehozni. A MazePrototypeFactory alosztályt az általa 
létrehozandó objektum prototípusaival fogjuk előkészíteni, hogy ne kelljen alosztályokat 
készíteni belőle a létrehozott falak és szobák megváltoztatásához. 


A MazeprototypeFactory kiegészíti a MazeFactory felületét egy konstruktorral, 
amely a prototípusokat veszi fel argumentumként: 


Prototípus 
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class MazePrototypeFactóry : public MazeFactory ( 
public: 
MazePrototypeFactory (Mazer, Wall§, Room", Door"); 


virtual Mazet MakeMaze() const; 

virtual Room! MakeRoom(int) const; 

virtual Wall" MakeWall() const; 

virtual Door MakeDoor(Roomt, Roomt) const; 


private: 
Mazet  prototypeMaze; 
Roomt . prototypeRoom; 
Wally prototypeWall; 
Doort  prototypeDoor; 
Ja 


Az új konstruktor egyszerűen csak előkészíti saját prototípusait: 


MazePrototypeFactory : :MazePrototypeFactory ( 
Mazet m, Wally w, RoomY r, DoorY" d 


.prototypeMaze - m; 
.prototypeWall - w; 
.prototypekRoom - r; 
.prototypeDoor - d; 


A falakat, szobákat és ajtókat létrehozó tagfüggvények hasonlóak: mindegyik klónoz, majd 
előkészít egy prototípust. Alább a Makewal1 (KészítFal) és a MakeDoor (KészítAjtó) műve- 
let meghatározása látható: 


Wall" MazePrototypeFactory: :MakeWall () const ( 
return ,. prototypeWall-5Clone () ; 


Doööort MazePrototypeFactory: :MakeDoor (Room? ri, Room tr2) const ( 
Doort door - . prototypeDoor-5Clone ( ) ; 
door-sInitializeíri, r2); 
return door; 


A MazePrototypeFactory alosztályt prototípusos és alapértelmezett labirintus létreho- 
zására használhatjuk, mindössze annyi a teendőnk, hogy a labirintus alapösszetevőinek 
prototípusaival állítsuk be: 
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MazeGame game; 
MazePrototypeFactory simpleMazeFactory( 
new Maze, new Wall, new Room, new Door 


); 


Mazet maze - game.CreateMaze(simpleMazeFactory) ; 


A labirintus típusának megváltoztatásához másféle prototípushalmazzal állítjuk be a Maze- 
PrototypeFactory alosztályt. A következő hívás egy olyan labirintust hoz létre, amely- 
nek egyik szobájában bomba robbant (RoomWithABomb), és ettől kiszakadt az ajtó is 
(BombedDoor): 


MazePrototypeFactory bombedMazeFactory( 
new Maze, new BombedWall, 
new RoomWithABomb, new Door 

); 


A prototípusként használható objektumnak - ez lehet például a wal1 osztály egy példánya — 
támogatnia kell a Clone műveletet, és rendelkeznie kell egy másoló konstruktorral, ami 
klónozza. Emellett szüksége van még egy külön műveletre, amely újra előkészíti a belső ál- 
lapotot. Az Initialize műveletet a Door osztályhoz adjuk hozzá, hogy az ügyfél előké- 
szíthesse a klónozott szobákat. 


Hasonlítsuk össze a Door osztály alábbi meghatározását a fejezet elején találhatóval: 


class Door : public MapSite ( 
public: 

Door () ; 

Door(const Door6); 


virtual void Initialize(Roomt, Roomt) ; 
virtual DoorY Clone() const; 


virtual void Enter (); 

Roomt OtherSideFrom(Roomt ) ; 
private: 

Roomt . roomi ; 

Roomt . room2 ; 
); 


Door::Door (const Doorg other) ( 
.-roomi - other. rooml; 
.room2 - other. room2; 
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void Door::Initialize (RoomY r1l, Roomt r2) ( 
.rooml z r1z 
-YVÖGÖM2 z £2; 


) 


Door$t Door::Clone () const ( 
return new Door("this) ; 


) 


A BombedWal1 alosztálynak felül kell bírálnia a Clone műveletet, és meg kell valósítania 
egy megfelelő másoló konstruktort: 


class BombedWall : public Wall ( 
public: 

BombedWal1 ( ) ; 

BombedWall(const BombedWall£); 


virtual Wally Clone() const; 
bool HasBomb( ) ; 

private: 
bool . bomb; 

1; 


BombedWal1 : : BombedWall (const BombedWallg other) : Wall(other) ( 
-bomb - other. bomb; 
k 


Wallt BombedWall::Clone () const ( 
return new BombedWall("this) ; 


Bár a BombedWall : : Clone művelet egy Wall" mutatót ad vissza, megvalósítása egy 
olyan mutatót, amely egy új alosztálypéldányra (Bombedwal1") mutat. A Clone műveletet 
az alaposztályban határozzuk meg így, ezzel biztosítva, hogy a prototípust klónozó ügyfe- 
leknek ne kelljen tudniuk saját konkrét alosztályaikról. Az ügyfeleknek sohasem kell lefelé 
irányuló átalakítást végezniük a Clone művelet által visszaadott értéken. 


A Smalltalk nyelvben az Object osztályból örökölt szabványos copy metódust újra fel- 
használhatjuk bármely MapSite osztály klónozására. A MazeFactory osztály a szükséges 
prototípusok előállítására használható: a iroom nevet megadva például létrehozhatunk 
egy szobát. A MazeFactory alosztályhoz tartozik egy szótár is, amely a neveket a prototí- 
pusokhoz rendeli. Az alosztály make : metódusa így néz ki: 


make: partName 
" (partCatalog at: partName) copy 
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Amennyiben adottak a MazeFactory prototípusokkal való előkészítéséhez szükséges me- 
tódusok, az alábbi kóddal létrehozhatunk egy egyszerű labirintust: 


CreateMaze 
on: (MazeFactory new 
with: Door new named: tdoor; 
with: Wall new named: twall; 
with: Room new named: tHtroom; 
yourself) 


A CreateNaze alosztály fenti kódban szereplő on: osztálymetódusának meghatározása 
a következő lehet: 


on: aFactory 
rooml room2 I 


rooml :- (aFactory make: troom) location: 1681. 

room2 :- (aFactory make: troom) location: 281. 

door :- (aFactory make: tdoor) from: roomi to: room2. 
rooml 


atSide: tnorth put: (aFactory make: twall); 
atSide: teast put: door; 
atSide: tssouth put: (aFactory make: twall) ; 
atSide: twest put: (aFactory make: twall). 
room2 
atSide: tnorth put: (aFactory make: twall); 
atSide: teast put: (aFactory make: twall); 
atSide: tsouth put: (aFactory make: Hwall); 
atSide: twest put: door. 
" Maze new 
addíRoom: rooml; 
addRoom: room2; 
yourself 


Ismert felhasználások 


A Prototípus minta felhasználásának első példája talán Ivan Sutherland Sketchpad rendsze- 
re ISutó3] lehetett. Az első széles körben ismert alkalmazás, amely a mintát egy objektum- 
központú nyelvben használta, a ThingLab volt, amelyben a felhasználók egy összetett ob- 
jektumot állíthattak össze, majd továbbadhatták azt egy prototípusnak úgy, hogy egy olyan 
könyvtárban helyezték el, amelyben újrafelhasználható objektumok voltak találhatók 
[Bor81]. Goldberg és Robson is említi a mintaként használható prototípusokat [GR83], de 
Coplien [Cop92] sokkal teljesebb leírást ad róluk, ismertetve a C4-- nyelvben a Prototípus 
mintához kapcsolódó megoldásokat, és bemutat számos példát és változatot. 
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Az etgdb egy hibakereső-felületi alkalmazás, amely az ET--4-on alapul, és grafikus (egérmű- 
veletekkel kezelhető) felhasználói felületet biztosít különféle programsorból futtatható hiba- 
keresőkhöz. Mindegyik hibakeresőnek megvan a megfelelő DebuggerAdaptor (Hiba- 
keresőlllesztő) alosztálya. A GdbAdaptor például a GNU gdb nyelvtanához illeszti az etgdb 
programot, míg a SunDbxAdaptor a Sun dbx hibakeresőjéhez. Az etgdb programba nincs me- 
reven bekódolva a DebuggerAdaptor osztályhalmaz. Ehelyett a program egy környezeti vál- 
tozóból olvassa ki a használandó illesztő nevét, kikeresi egy globális táblázatból az adott ne- 
vű prototípust, majd klónozza. Az etgdb programhoz új hibakereső programok is hozzáadha- 
tók, ehhez csak az adott hibakeresőhöz tartozó DebuggerAdaptor illesztőt kell csatolnunk. 


A Mode Composerben található , együttműködési könyvtár" (interaction technigue library) 
tárolja azon objektumok prototípusait, amelyek támogatják a különféle interaktív eljáráso- 
kat ISha90]. A Mode Composer által létrehozott összes ilyen eljárás használható prototípus- 
ként, ha a fent említett könyvtárban helyezzük el. A Prototípus minta lehetővé teszi, hogy 
a Mode Composer korlátlan számú interaktív eljárást használhasson. 


A korábban említett kottaszerkesztő a Unidraw rajzoló keretrendszeren alapszik IVL90]. 


Kapcsolódó minták 


A Prototípus és az Elvont gyár bizonyos fokig vetélytársai egymásnak, amint arról majd a fe- 
jezet végén szó lesz, de együtt is használhatók. Az Elvont gyár tárolhat egy olyan prototí- 
pushalmazt, amelynek elemeit aztán klónozzuk, és az így készült termékobjektumokat ad- 
juk vissza. 


Az Összetétel és a Díszítő mintákat sokat használó programok gyakran szintén nagy hasz- 
nát veszik a Prototípus mintának. 
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Egyke 


Objektum-létrehozási minta 


Egyéb nevek 


Singleton 
Cél 


Egy osztályból csak egy példányt engedélyezni, és ehhez globális hozzáférési pontot meg- 
adni. 


Feladat 


Egyes osztályok esetében fontos, hogy pontosan egy példány legyen belőlük. Bár egy rend- 
szerben több nyomtató is lehet, nyomtatási sorból csak egyet szabad használni, Csak egy 
fájlrendszer és csak egy ablakkezelő futhat. Egy digitális szűrőhöz egyetlen analóg-digitális 
átalakító tartozhat. Egy könyvelőrendszer egy cég kiszolgálására van beállítva. 


Hogyan biztosíthatjuk, hogy egy osztályból csak egyetlen példány legyen, viszont azt 
könnyen el lehessen érni? Egy globális változóval az objektum elérhetővé tehető, de ez 
nem jelent védelmet az ellen, hogy az objektumból több példány készüljön. 


Jobb megoldás, ha magát az osztályt tesszük felelőssé annak nyilvántartásáért, hogy ké- 
szült-e már példány belőle. Az osztály biztosítani tudja, hogy több példányt ne lehessen be- 
lőle létrehozni (úgy, hogy elfogja az új objektum készítésére vonatkozó kérelmeket), és ké- 
pes biztosítani azt is, hogy a példányt el lehessen érni. Ez az Egyke minta. 


Alkalmazhatóság 


Az Egyke mintát a következő esetekben használjuk: 


, Pontosan egy példányra van szükség valamelyik osztályból, és annak elérhetőnek 
kell lennie az ügyfelek számára a jól ismert elérési pontokból. 

" Ennek az egyetlen példánynak alosztályokkal bővíthetőnek kell lennie, és az ügyfe- 
leknek képeseknek kell lenniük saját kódjuk módosítása nélkül használni a bővített 
példányt. 
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Szerkezet 








j- Egyke 


static Példány() 0---g---- et retum egyediPéldány 
EgykeMűvelet() 
SzerezEgykeAdat() 


static egyediPéldány 
egykeAdat 


Résztvevők 


e Egyke 
— Meghatároz egy olyan Példány (Instance) műveletet, amely lehetővé teszi, hogy 
az ügyfelek hozzáférjenek az osztály egyedi példányához. A Példány osztálymű- 
velet (azaz osztálymetódus a Smalltalk nyelvben, illetve statikus tagfüggvény 
a Ct4-ban). 
— Felelős lehet saját egyedi példányának létrehozásáért. 





Együttműködés 


s Az ügyfelek az Egyke példányt kizárólag az Egyke Példány műveletén át érik el. 


Következmények 


Az Egyke mintának számos előnye van: 


1. Szabályozott hozzáférés az egyetlen példányhoz. Mivel az Egyke osztály magába 
zárja saját egyetlen példányát, szigorúan szabályozhatja, hogy az ügyfelek mikor és 
hogyan férhessenek hozzá. 

2. Csökkentett névtér. Az Egyke minta jobb a globális változóknál, mert elkerülhető ve- 
le a névtérnek az egyetlen példányt tároló globális változókkal szennyezése. 

3. Megengedi a műveletek és a megjelenítés finomítását. Az Egyke osztályból létrehoz- 
hatók alosztályok, és az alkalmazások futásidőben egyszerűen beállíthatók a szüksé- 
ges bővített osztály egy példányával. 

4. Megengedi változó számú példány használatát. A minta megkönnyíti, hogy ha meg- 
gondoljuk magunkat, az Egyke osztályból egynél több példány használatát is enge- 
délyezzük. Emellett ugyanezt a megközelítést használhatjuk az alkalmazás által hasz- 
nált példányok számának szabályozására is, ehhez csak azt a műveletet kell megvál- 
toztatnunk, amely az Egyke példányhoz való hozzáférést engedélyezi. 
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5. Rugalmasabb, mint az osztályműveletek. Az egykék szolgáltatásait osztályművele- 


tekkel is megvalósíthatjuk, azaz a Cs nyelvben statikus tagfüggvényeket, a Small- 
talkban osztálymetódusokat használva, de mindkét megoldás megnehezíti a kialakí- 
tás oly módon történő megváltoztatását, hogy az megengedje egy osztály több pél- 
dányának használatát is. Ezenkívül a C--4- nyelvben a statikus tagfüggvények soha- 
sem virtuálisak, így az alosztályok nem tudják azokat a többalakúság segítségével fe- 
lülbírálni. 


Megvalósítás 


Az Egyke minta megvalósításánál az alábbiakat kell szem előtt tartanunk: 


1. Egyedi példány biztosítása. Az Egyke minta az egyetlen példányt normál osztálypél- 


dánnyá alakítja, de ezt az osztályt úgy kell megírni, hogy mindig csak egy példányt 
lehessen belőle létrehozni. Erre gyakran használt módszer, hogy a példányt létreho- 
zó műveletet elrejtik egy olyan osztályművelet (azaz statikus tagfüggvény vagy osz- 
tálymetódus) mögé, ami garantálja, hogy csak egy példányt lehet létrehozni egy osz- 
tályból. Ez a művelet hozzáférhet ahhoz a változóhoz, amely az egyedi példányt tá- 
rolja, és gondoskodik arról, hogy a változó értékének visszaadása előtt az egyedi 
példányt kapja kezdőértékként. Ez a megközelítés biztosítja azt, hogy az egykét már 
első használatba vétele előtt létrehozza és előkészíti a program. 
Az osztályművelet a Ctt nyelvben a Singleton osztály Instance statikus függvé- 
nyével határozható meg. A Singleton osztály meghatározza az . instance statikus 
tagváltozót is, amely az osztály egyetlen példányát címző mutatót tartalmazza. 
A Singleton osztályt a következőképpen vezetjük be: 
class Singleton ( 
public: 
static Singletont Instance(); 
protected: 
Singleton() ; 
private: 
static Singletonyr . instance; 
1; 
Az ennek megfelelő megvalósítás: 
Singletont Singleton:: instance - 0; 


Singletont Singleton: :Instance () ( 
if ( instance -— 0) ( 
.-instance - new Singleton; 
) 
return . instance; 
) 
Az ügyfelek az egykéket kizárólag az Instance tagfüggvényen át érhetik el. 


Az. instance változó kezdőértéke 0, az Instance statikus tagfüggvény pedig en- 
nél az értéknél az egyedi példányra állítja, és visszaadja az értékét. Az Instance tag- 
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függvény lusta előkészítést használ, az általa visszaadott értéket a program nem hoz- 

Za létre és nem tárolja addig, amíg először hozzá nem férnek a példányhoz. 

Figyeljük meg, hogy a konstruktor védett. Ha egy ügyfél közvetlenül próbál pél- 

dányt készíteni a singleton osztályból, fordításkor hibaüzenetet kap. Ez biztosítja 

azt, hogy mindig csak egy példányt lehessen létrehozni. 

Ezenkívül, mivel az . instance egy egyke objektumra hivatkozó mutató, az 

Instance tagfüggvény egy Egyke alosztályt címző mutatót rendelhet e változóhoz, 

amint azt a Példakód részben is láthatjuk. 

Van még valami, amit érdemes megjegyezni a Ct-4 nyelven történő megvalósítással 

kapcsolatban. Nem elég az egykét globális vagy statikus objektumként meghatároz- 

ni, majd az automatikus előkészítésben bízni. Ennek három oka van: 

(a) Nem garantálható, hogy a statikus objektumnak mindig csak egy példánya lesz 
bevezetve. 

(b) Lehet, hogy a statikus előkészítés idején nem lesz elég információnk minden 
egyke példányosításához. Az egyke kérhet olyan értékeket, amelyeket a prog- 
ram a végrehajtás egy későbbi szakaszában számít ki. 

(c) A Cst nem határozza meg, hogy a globális objektumok konstruktorait milyen 
sorrendben kell meghívni a fordítási egységekben [ES90]. Ez azt jelenti, hogy az 
egykék közt nem lehet semmilyen függőségi viszony. Ha mégis van, a hibaüze- 
netek elkerülhetetlenek. 

Egy további (jóllehet kicsi) felelősség a globális-statikus objektumos megközelítés- 

ben, hogy kényszerűen létre kell hozni az egykéket, ha szükség van rájuk, ha nincs. 

Statikus tagfüggvényt használva minden ilyen gond elkerülhető. 

A Smalltalk nyelvben az egyedi példányt visszaadó függvény a Singleton osztály osz- 

tálymetódusa. Annak biztosítására, hogy csak egyetlen példány készüljön, a new mű- 

veletet bíráljuk felül. Az így kapott egykeosztálynak a következő két osztálymetódu- 
sa lehet, ahol a soleInstance (EgyetlenPéldány) egy olyan osztályváltozó, amelyet 
sehol máshol nem használunk: 
new 
self error: "nem hozható létre új objektum" 


default 
Solelnstance isNil ifTrue: [(Solelnstance :- super new]. 
" Solelnstance 


.  Alosztályok készítése az Egyke osztályhoz. A fő gond nem is igazán az alosztályok 
meghatározása, sokkal inkább az egyedi példány oly módon történő telepítése, 
hogy az ügyfelek képesek legyenek azt használni. Lényegében az egykepéldányra 
hivatkozó változónak az alosztály egy példányát kell adni kezdőértékként. A legegy- 
szerűbb módszer, ha meghatározzuk, melyik egykét szeretnénk használni az Egyke 
osztály Példány (instance) műveletével. A Példakód részben egy példa szemlélteti, 
hogy ezt a módszert hogyan lehet környezeti változók segítségével megvalósítani. 

Az Egyke osztály alosztályának kiválasztására egy másik módszer, ha az Instance 
művelet megvalósítását kivesszük a szülőosztályból (például a MazeFactory osz- 
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tálybóD, és egy alosztályba helyezzük. Ekkor a C-t programozó összeszerkesztés- 
kor döntheti el (például egy másfajta megvalósítást tartalmazó objektumfájlhoz csa- 
tolva), hogy melyik egykeosztályt akarja használni, de továbbra is rejtve tartja az egy- 
két az azt használó ügyfelek elől. 
Ez a megközelítés az összeszerkesztésre időzíti az egykeosztály kiválasztását, ami 
megnehezíti azt, hogy az egykeosztályt futásidőben választhassuk ki. Ha feltételes 
utasításokat használunk az alosztály meghatározására, az rugalmasabb, de mereven 
bekódolja a választható Egyke osztályokat. Egyik megoldás sem elég rugalmas ah- 
hoz, hogy minden esetben kielégítő eredményt adjon. 
Sokkal rugalmasabb módszer ezeknél az egykenyilvántartó használata. Ahelyett, hogy 
egy Instance művelettel határoznánk meg a választható Egyke osztályokat, azok 
név szerint bejegyeztethetik egykepéldányukat egy ismert nyilvántartóba. 
A nyilvántartó elvégzi a név-karakterláncok és az egykék egymáshoz rendelését. Ami- 
kor az Instance műveletnek egy egykére van szüksége, a nyilvántartóhoz fordul, és 
név szerint kéri a kívánt egykét. A nyilvántartó megkeresi a megfelelőt (ha az létezik), 
és visszaadja az Instance műveletnek. Ezt a megközelítést használva az Instance 
műveletnek nem kell ismernie az összes választható egykeosztályt vagy példányt, az 
egyetlen követelmény, hogy legyen egy olyan közös felület az összes Egyke 
CSingleton) osztályhoz, amely tartalmazza a nyilvántartóval kapcsolatos műveleteket: 
class Singleton ( 
public: 
static void Register(const chart name, Singletont ) ; 
static Singletont Instance(); 
protected: 
static Singletont Lookup(const chart name) ; 
private: 
static Singletont ,. instance; 
static List-NameSingletonPairst registry; 
); 
A Register (Nyilvántartó) a megadott néven tartja nyilván a Singleton példányt. 
Hogy a nyilvántartó egyszerű maradjon, tároltatnunk kell vele egy NameSingle- 
tonPair (NévEgykePár) objektumlistát, amelyben minden NamegSingletonPair 
elem egy nevet rendel egy egykéhez. A Lookup (Keresés) művelet a nevük alapján 
keresi meg az egykéket. Tételezzük fel, hogy a keresett egyke nevét egy környezeti 
változó adja meg: 
Singletont Singleton: :Instance () ( 
if ( instance -- 0) ( 
const chart singletonName - getenyv("SINGLETON" ) ; 
//ezt a felhasználó vagy a környezet adja meg indításkor 


—-instance - Lookup(ísingletonName) ; 
//Ha nincs ilyen egyke, a Lookup művelet 0-t ad vissza 


Fj 


return , instance; 
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Hol jegyeztetik be magukat a Singleton osztályok? Például a konstruktorukban (mint 
egyik lehetőség). A MysSingleton alosztály például a következőt teheti: 
MySingleton: :MySingleton() ( 
tf ses 
Singleton: :Register ( "MySingleton", this); 
) 


Természetesen a konstruktort nem lehet meghívni, csak ha valaki előbb példányosít- 
ja az osztályt — ami ugyanazt a problémát tükrözi, mint amit az Egyke minta megpró- 
bál megoldani! A Cs nyelvben a probléma úgy kerülhető meg, ha egy statikus pél- 
dányt határozunk meg a MySingleton alosztályból. A MySingleton megvalósítását 
tartalmazó fájlban meghatározhatjuk például ezt: 
static MySingleton theSingleton; 

A Singleton osztály ezek után már nem felelős az egyke létrehozásáért, helyette el- 
sődleges felelőssége az, hogy a tetszés szerinti egykeobjektumot elérhetővé tegye 
a rendszerben. Ennek a statikus objektumos megközelítésnek még mindig van egy 
lehetséges hátulütője — nevezetesen az, hogy az összes lehetséges Egyke alosztály 
példányait létre kell hozni, különben nem lesznek bejegyezve a nyilvántartóba. 


Példakód 


Tételezzük fel, hogy egy MazeFactory osztályt határozunk meg labirintusok létrehozásá- 
hoz, amint azt a fejezet elején láthattuk. A MazeFactory osztály egy felületet határoz meg, 
amelynek segítségével a labirintus különféle elemei hozhatók létre. Az alosztályok felülír- 
ják a műveleteket, hogy egyedi célú termékosztály-példányokat adjanak vissza, amilyenek 
például a Bombedwal11 objektumok az egyszerű wall objektumok helyén. 


Ami itt fontos, az az, hogy a Maze alkalmazásnak a labirintusgyárakból csak egy példányra 
van szüksége, és hogy ennek a példánynak hozzáférhetőnek kell lennie a labirintus bárme- 
lyik részét felépítő kódok számára. Ez az a pont, ahol az Egyke minta szerepet kap. 
Ha a MazeFactory osztályt egykeként hozzuk létre, a labirintusobjektum mindenhonnan 
elérhető lesz globális változók használata nélkül is. 


Az egyszerűség kedvéért tételezzük fel, hogy soha nem kell alosztályt készítenünk 
a MazeFactory osztályból (kisvártatva a másik lehetőséget is meg fogjuk vizsgálni). Ekkor 
a MazeFactory osztályt Egyke osztállyá változtatjuk, a Ctt nyelvben egy statikus 
Instance műveletet és az egyetlen példányt tároló statikus instance tagot adva hozzá. 
A konstruktort védenünk is kell, hogy megakadályozzuk a véletlen példányosítást, aminek 
következtében esetleg több példány jöhetne létre. 


class MazeFactory ( 
public: 
static MazeFactoryy Instancet(() ; 
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//ide jön a már meglévő felület 
protected: 

MazeFactory (); 
private: 

static MazeFactory"" . instance; 
1; 


A megfelelő megvalósítás a következő: 


MazeFactoryt MazeFactory:: instance - 0; 


MazeFactoryt MazeFactory: :Instance () ( 
if ( instance -- 0) ( 
-instance - new MazeFactory; 
) 


return . instance; 


Most vegyük azt az esetet, amikor alosztályokat is készítünk a MazeFactory osztályból, és 
az alkalmazásnak kell eldöntenie, hogy melyiket használja. A labirintus típusát egy környe- 
zeti változó segítségével választjuk ki, és a kódot kiegészítjük egy olyan kódrésszel, amely 
a megfelelő MazeFactory alosztályokat példányosítja a környezeti változó értéke alapján. 
Az Instance művelet kiváló hely ennek a kódnak a hozzáadására, mivel már önmagában 


is példányosítja a MazeFactory osztályt: 


MazeFactoryt MazeFactory: :Instance () ( 
if ( instance -—- 0) ( 


const chart mazeStyle - getenv("MAZESTYLE" ) ; 


if (strcmp(mazeStyle, "bombed") -- 0) 
-instance - new BombedMazeFactory; 


) else if (strcmp(mazeStyle, "enchanted") 
—-instance - new EnchantedMazeFactory; 


//...további lehetséges alosztályok 


) else ( // alapértelmezés 
.-instance - new MazeFactory; 


3 


return . instance; 


Figyeljük meg, hogy az Instance műveletet minden esetben módosítani kell, amikor új al- 
osztályt határozunk meg a MazeFactory osztályhoz. Ez ebben az alkalmazásban talán 
nem gond, de a keretrendszerrel meghatározott elvont gyárak esetében az lehet. 
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Az egyik lehetséges megoldás lehet a Megvalósítás részben ismertetett nyilvántartó haszná- 
lata. Hasznos lehet a dinamikus kötés is, ami megakadályozza, hogy az alkalmazás a nem 
használt alosztályokat is betöltse, 


Ismert felhasználások 


A Smalltalk 80-ban [Par90] használt Egyke mintára egy példa a ChangeSet current nevű 
kódmódosítás-halmaz. Egy kifinomultabb példa az osztályok és metaosztályaik közötti kap- 
csolat. A metaosztály az osztályok osztálya, és mindegyik metaosztálynak egy példánya van. 
A metaosztályoknak nincs nevük (kivétel: közvetve az egyetlen példányukon keresztül), de 
nyilvántartják az egyetlen példányukat, és normál esetben nem hoznak létre másikat. 


Az InterViews felhasználói felületi elemkészlet ILCI--92] többek közt Session és WidgetKit 
osztályai egyedi példányainak elérésére használ egykéket. A Session (Munkamenet) az al- 
kalmazás fő eseményelosztó ciklusát határozza meg, tárolja a felhasználó stílusbeállításait 
tartalmazó adatbázist, és kezeli az egy vagy több fizikai kijelzővel való kapcsolatokat. 
A Widgetkit egy Elvont gyár, amely a felhasználói felület vizuális kialakításában szereplő 
elemeket határozza meg. A WidgetkKit : : Instance ( ) művelet azt az adott WidgetKit al- 
osztályt határozza meg, amelyet egy, a Session osztály által meghatározott környezeti válto- 
zó alapján példányosít a rendszer. A Session osztályon végrehajtott hasonló művelet meg- 
határozza, hogy a rendszer a monokróm vagy a színes kijelzőket támogatja-e, és ennek 
megfelelően beállítja a Session egykepéldányt. 


Kapcsolódó minták 


Az Egyke mintával számos minta megvalósítható, például az Elvont gyár, az Építő és 
a Prototípus. 
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A létrehozási mintákról 


A rendszernek az általa létrehozott osztályokkal történő paraméterezésére általában két 
módszert használnak. Az egyik az alosztályok készítése az objektumot létrehozó osztályok- 
ból, ennek megfelelője a Gyártófüggvény minta használata. Ennek a módszernek a legfőbb 
hátulütője, hogy esetenként új alosztályt kell létrehozni csak azért, hogy megváltoztassuk 
a termékosztályt, és ezek a módosítások halmozódhatnak. Ha például magát a terméklétre- 
hozót is gyártófüggvénnyel hoztuk létre, akkor felül kell bírálnunk a készítő osztályt is. 


A rendszer paraméterezésének másik módja sokkal inkább az objektum-összetételen alap- 
szik: meghatározunk egy objektumot, amely felelős azért, hogy ismerje a termékobjektu- 
mokat, és ezt az objektumot használjuk rendszerparaméterként. Ez a kulcsa az Elvont gyár, 
az Építő és a Prototípus mintáknak. Mindhárom mintánál létrehozunk egy új ,gyárobjektu- 
mot", amelynek felelőssége a termékobjektumok létrehozása. Az Elvont gyár mintában 
a gyárobjektum több osztály objektumait állítja elő. Az Építő mintában a gyárobjektum fo- 
kozatosan összetett terméket készít, egy megfelelően összetett protokollt használva. A Pro- 
totípus mintában a gyárobjektum a prototípusobjektumot lemásolva hozza létre a terméke- 
ket. Ebben az esetben a gyárobjektum és a prototípus ugyanaz az objektum, mivel a proto- 
típus felel a termék visszaadásáért. 


Vegyük most a Prototípus mintánál említett rajzszerkesztő keretrendszert. A GrafikusEszköz 
osztályt a termékosztály többféleképpen is paraméterezheti: 


s A Gyártófüggvény mintával a GrafikusEszköz osztály egy alosztálya jön létre a palet- 
tán lévő minden Grafika alosztályhoz. A GrafikusEszköz osztálynak lesz egy Új- 
Grafika (NewGraphic) művelete, amelyet minden GrafikusEszköz alosztály felülír. 

e Az Elvont gyár mintával a GrafikaGyár (GraphicsFactory) osztályok osztályhierarchi- 
ája jön létre, minden Grafika alosztályhoz egy. Ebben az esetben mindegyik gyár 
csak egy terméket állít elő: a KörGyár (CircleFactory) köröket, a VonalGyár (Line- 
Factory) vonalakat stb. A GrafikusEszköz osztályok paramétere az adott Grafika al- 
osztálytípust előállító gyár lesz. 

s A Prototípus mintában a Grafika osztály minden alosztálya a Klónoz (Clone) művele- 
tet valósítja meg, és a GrafikusEszköz osztályok az általuk létrehozott Grafika osztály 
prototípusát kapják paraméterként. 


Az, hogy melyik mintát a legcélszerűbb alkalmazni, számos tényezőtől függ. A rajzszer- 
kesztő keretrendszerben a Gyártófüggvény minta használata tűnik elsőre a legkönnyebb- 
nek. Egyszerű a GrafikusEszköz osztályhoz új alosztályt meghatározni, és a GrafikusEszköz 
példányait csak akkor hozza létre a program, amikor a paletta már elkészült. A fő hátrány itt 
az, hogy a GrafikusEszköz alosztályok elburjánzanak, és egyik sem végez túl sok munkát. 
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Az Elvont gyár sem sokkal jobb, mert ehhez egy ugyanolyan nagy GrafikaGyár osztályhie- 
rarchia szükséges, Az Elvont gyár a Gyártófüggvényhez képest csak akkor jelent előnyt, ha 
a GrafikaGyár hierarchia már létezik — vagy azért, mert a fordítóprogram automatikusan 
biztosítja (mint a Smalltalk és az Objective C nyelvben), vagy azért, mert a rendszer egy má- 
sik részéhez szükség van rá. 


Mindent összevetve a rajszerkesztő keretrendszerhez valószínűleg a Prototípus minta a leg- 
megfelelőbb, mert ezt használva csak a Klónoz műveletet kell megvalósítani minden 
Graphics osztályon. Ezzel csökken az osztályok száma, és a Klónoz művelet a puszta pél- 
dányosításon kívül más célokra is használható (például egy Másolatkészítés nevű menü- 
pont műveletekénD. 


A Gyártófüggvény mintát használva testreszabhatóbbak lesznek a programok, és csak alig 
valamivel bonyolultabbak. A többi tervezési minta új osztályokat igényel, míg a Gyártófügg- 
vény csak egy új műveletet. A Gyártófüggvény mintát gyakran használják objektumok létre- 
hozásának szokásos megoldásaként, de ha a példányosított osztály soha nem változik meg, 
vagy ha a példányosítás olyan műveleten belül történik, amelyet az alosztályok könnyen fe- 
lülbírálhatnak (amilyen például az előkészítési művelet), akkor nincs rá szükség. 


Az Elvont gyár, a Prototípus és az Építő mintát használó programok még rugalmasabbak, 
mint a Gyártófüggvényt használók, de bonyolultabbak is. A tervezés gyakran a Gyártófügg- 
vény mintát használva indul el, és onnan fejlődik tovább a többi létrehozási minta használa- 
tának irányába, ahogy a programtervező rájön, hogy nagyobb rugalmasságra van szükség. 
Ha több tervezési mintát ismerünk, több lehetőségünk lesz, hogy válasszunk közülük. 





Szerkezeti minták 


A szerkezeti minták közzépontjában az áll, hogy az osztályokból és objektumokból hogyan 
alkothatunk nagyobb szerkezeteket. A szerkezeti osztályminták örökléssel felületeket vagy 
megvalósításokat építenek fel, egyszerű példaként gondoljunk csak arra, hogyan lehet 
többszörös örökléssel két vagy több osztályt egybe , keverni", amely aztán szülőosztályai- 
nak tulajdonságait egyesíti. A minta különösen hasznos lehet, ha önállóan fejlesztett osz- 
tálykönyvtárak együttműködésését szeretnénk biztosítani. Egy másik példa az Illesztő min- 
ta osztályformája: az illesztő általában arra szolgál, hogy egy felületet (az illesztendő felüle- 
tét) egy másikhoz igazítson, s így különböző felületek egységes elvont ábrázolását nyújtsa. 
Az osztályillesztők ezt egy illesztendő osztályból való privát örökléssel érik el; az illesztő 
ezután felületét az illesztendő nyomán határozza meg. 





A szerkezeti objektumminták felületek vagy megvalósítások összetétele helyett azt írják le, 
hogyan ragaszthatunk össze objektumokat, hogy új szolgáltatásokat nyújtsunk. Az objek- 
tum-összetétel rugalmasságát az összetétel futásidejű megváltoztathatósága biztosítja, ami 
a statikus osztályösszetétellel nem érhető el. 





Az Összetétel szerkezeti objektumminta, amelynek segítségével osztályhierarchiát építhe- 
tünk fel kétféle objektumosztályból: alapvető (primitív) és összetett objektumokból. 
Az alap- és összetett objektumokból tetszőlegesen bonyolult szerkezetek építhetők. A He- 
lyettes mintában a helyettes egy másik objektum , helyőrzője" vagy helyettesítője. A helyet- 
tes számos módon használható: lehet egy távoli címtér objektumának helyi képviselője, je- 
lölhet egy igény szerint betöltendő nagy objektumot, de arra is használható, hogy megaka- 
dályozzuk egy érzékeny objektum elérését. A helyettesekkel elérhető, hogy az objektumok 
egyes tulajdonságaihoz csak közvetetten férhessünk hozzá; segítségükkel e tulajdonságok 
korlátozhatók, bővíthetők vagy módosíthatók. 
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A Pehelysúlyú minta objektumok megosztására biztosít szerkezetet. Objektumokat leg- 
alább két okból oszthatunk meg: a hatékonyság növelése vagy a következetesség biztosítá- 
sa céljából. A Pehelysúlyú minta a jobb tárkihasználást célozza meg. A számos objektumot 
használó alkalmazásoknak különösen ügyelniük kell; az objektumok lemásolása helyett 
azok megosztása jelentősen csökkentheti a költségeket. Mindazonáltal az objektumok csak 
akkor oszthatók meg, ha állapotuk nem függ a környezettől; a Pehelysúlyú objektumok 
nem is tárolnak környezetfüggő állapotot, a feladatuk elvégzéséhez igényelt kiegészítő in- 
formációkat akkor kapják meg, amikor szükségük van rájuk. Környezetfüggő állapot híján 
így a Pehelysúlyú objektumok szabadon megoszthatók. 


Amíg a Pehelysúlyú minta azt mutatja meg, hogyan készíthetünk sok-sok apró objektumot, 
a Homlokzat minta arra ad megoldást, hogyan ábrázolhatunk egy teljes alrendszert egyet- 
len objektummal. A homlokzat objektumok halmazát képviseli, feladatait pedig úgy hajtja 
végre, hogy üzeneteket továbbít ezen objektumoknak. A Híd minta az elvont ábrázolást és 
a megvalósítást választja el egymástól, így azok egymástól függetlenül módosíthatók. 


A Díszítő minta azt írja le, hogyan adhatunk objektumokhoz dinamikusan felelősségi körö- 
ket. A Díszítő olyan szerkezeti minta, amely önhívással (rekurzióval) állít össze objektumo- 
kat, így téve lehetővé korlátlan számú új szolgáltatás felvételét. Egy felhasználói felületi ele- 
met tartalmazó Díszítő objektum például szegéllyel vagy árnyékolással, esetleg olyan szol- 
gáltatásokkal, mint a görgethetőség vagy a nagyíthatóság egészítheti ki az elemet. Kétféle 
díszítés hozzáadásához egyszerűen csak be kell ágyaznunk egy Díszítő objektumot egy 
másikba; további egymásba ágyazással pedig még több díszítést alkalmazhatunk. Mindeh- 
hez az szükséges, hogy a Díszítő objektumok illeszkedjenek a hozzájuk tartozó elem felü- 
letéhez, és üzeneteket küldjenek annak. A Díszítő feladatát (például egy szegély rajzolását 
az elem köré) az üzenet továbbítása előtt és után is elvégezheti. 


A szerkezeti minták közül számos kapcsolódik egymáshoz; ezeket a kapcsolatokat a fejezet 
végén tárgyaljuk. 
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Szerkezeti objektumminta/osztályminta 
z 
Cél 


Az adott osztály felületét az ügyfelek által igényelt felületté alakítani. E módszerrel az 
egyébként összeférhetetlen felületű osztályok együttműködését biztosíthatjuk. 


Egyéb nevek 


Adapter, Burkoló (Wrapper) 


Feladat 


Néha előfordul, hogy egy újrahasznosításra tervezett elemkészlet mégsem használható fel, 
mert felülete nem felel meg az adott alkalmazás tartományfüggő felületének. 


Vegyünk például egy rajzszerkesztőt, amelynek segítségével a felhasználók grafikus eleme- 
ket (vonalakat, sokszögeket, szöveget stb.) rajzolhatnak és rendezhetnek képekbe, illetve 
diagramokba. A rajzprogram kulcsfogalma a rajzobjektum, amelynek szerkeszthető alakja 
van, és képes kirajzolni önmagát. A rajzobjektumok felületét az Alakzat (Shape) elvont osz- 
tály határozza meg; a program ebből származtat alosztályokat az egyes rajzobjektum-típu- 
sok számára, így lesz például a VonalAlakzat (LineShape) a vonalak osztálya, a Sokszög- 
Alakzat (PolygonShape) a sokszögeké, és így tovább. 


Az alapvető mértani alakzatok osztályai — amilyen a VonalAlakzat és a SokszögaAlakzat is — vi- 
szonylag könnyen megvalósíthatók, mert rajzolási és szerkesztési lehetőségeik korlátozottak. 
Egy szöveg megjelenítésére és szerkesztésére képes SzövegAlakzat (TextShape) nevű alosz- 
tály megvalósítása azonban már lényegesen nehezebb, mert még az alapvető szövegszer- 
kesztési műveletek is bonyolult képernyőfrissítés- és átmenetitár-kezelést igényelnek. Egy 
boltban megvásárolható felhasználói felületi elemkészletben persze valószínűleg találunk egy 
megfelelően bonyolult, előre elkészített TextView (SzövegNézeD osztályt, amellyel szöveget 
jeleníthetünk meg és szerkeszthetünk. Ideális esetben ennek újrahasznosításával megvalósít- 
hatnánk a SzövegAlakzat osztályt — csakhogy a TextView-t nem a mi Alakzat osztályainkhoz 
tervezték, ezért a TextView és Alakzat objektumok egymással nem cserélhetők fel. 


Hogyan használható fel tehát egy olyan , idegen" osztály, mint a TextView, egy olyan alkal- 
mazásban, amely más, eltérő felületű osztályokat vár? Esetleg módosíthatnánk az osztályt, 
1ogy megfeleljen az Alakzat felületnek, de az elemkészlet forráskódjának híján erről le kell 
tennünk. De még ha rendelkeznénk is a forrással, akkor sem lenne sok értelme a TextView 
módosításának, hiszen az elemkészletet nem arra szánták, hogy pusztán egy adott alkalma- 
zás működését biztosítandó alkalmazkodjon az adott tartományra jellemző felülethez. 
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Ehelyett a SzövegaAlakzat osztályt kell úgy meghatároznunk, hogy a TextView felületét az 
Alakzatéhoz illessze. Ezt kétféleképpen érhetjük el: (1) az Alakzat felületének és a TextView 
megvalósításának öröklésével, vagy (2) egy TextView példány összeállításával egy Szöveg- 
Alakzaton belül, és a SzövegAlakzatnak a TextView felület alapján történő megvalósításá- 
val. A két megközelítés megfelel az Illesztő minta osztály- és objektumváltozatának. Az II- 
esztő szerepét a SzövegAlakzat tölti be. 


RajzSzerkesztő ——— re Alakzat TextView 















































BefoglalóDobozí) GetExtent() 
LétrehozMódosítót) 
szöveg 
Vonal ] SzövegAlakzat 
§ n] 
BefoglalóDobozt) BefoglalóDoboz() agó sinlzszszé iz la retum szöveg—3 GetExtenti) 
LétrehozMódosítót) LétrehozMódosítót) Örreseg 
ztsez retum new SzövegMódosító ka 


A fenti diagram az objektumillesztő esetét mutatja. Látható, hogy az Alakzat osztályban be- 
vezetett Befoglalóboboz (BoundingBox) kérelmeket a TextView-ban meghatározott Get- 
Extent (SzerezkKiterjedés) kérelmekké alakítjuk. Mivel a SzövegAlakzat a TextView-t az 
Alakzat felülethez illeszti, a rajzolóprogram felhasználhatja az egyébként nem összeegyez- 
tethető felületű TextView osztályt. 


Az illesztő gyakran olyan szolgáltatásokért felelős, amelyeket az illesztett osztály nem bizto- 
sít. A diagramon látható, hogyan képes erre. A felhasználónak például képesnek kell lennie 
arra, hogy az egeret húzva új helyre helyezze az Alakzat objektumokat, de a TextView nem 
nyújt ilyen képességet. A SzövegAlakzat úgy pótolhatja ezt a hiányosságot, hogy megvaló- 
sítja az Alakzat LétrehozMódosító (CreateManipulator) műveletét, ami a megfelelő Módosí- 
tó (Manipulator) alosztály egy példányát adja vissza. 


A Módosító azon objektumok elvont osztálya, amelyek tudják, hogyan mozgassanak egy 
Alakzat objektumot a felhasználó tevékenységével összhangban, például új helyre húzza- 
nak egy alakzatot. A különböző alakzatokhoz külön-külön Módosító alosztályok tartoznak, 
a SzövegMódosító (TextManipulator) például a SzövegAlakzatnak megfelelő alosztály. Egy 
SzövegMódosító példány visszaadásával a SzövegAlakzat biztosíthatja a TextView-ból hi- 
ányzó, de az Alakzat által igényelt szolgáltatást. 
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Alkalmazhatóság 


Az Illesztő minta a következő esetekben alkalmazható: 


e Egy meglevő osztályt szeretnénk használni, de annak felülete nem a kívánságaink- 
nak megfelelő. 

e Olyan újrahasznosítható osztályt szeretnénk készíteni, amely képes együttműködni 
vele kapcsolatban nem álló, vagy előre nem ismert osztályokkal, vagyis olyan osztá- 
lyokkal, amelyek felülete nem feltétlenül illeszkedik. 

e (Csak az objektumillesztők esetében) Számos már létező alosztályt kell használnunk, 
de felületük alosztály-származtatással történő illesztése nem praktikus. Az objektum- 
illesztő szülőosztályának felületét képes más felületekhez illeszteni. 





Szerkezet 


Az osztályillesztő többszörös örökléssel illeszt egy felületet egy másikhoz: 





Ügyfél Cél ! ! Illesztendő 


Kérelem() 0 ! AdottKérelem() 

















AdottkKérelem() 


Az objektumillesztő objektum-összetételre épül: 






Ügyfél Illesztendő 








AdottKérelem() 


LN 





illesztendő 





illesztő 











Kérelem) : art ojhedázjezáemászdázmzase sb jássiat illesztendő- Adottkérelem() ke 
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Résztvevők 
s Cél(Alakza0 
— Meghatározza az Ügyfél által használt tartományra jellemző felületet. 
e Ügyfél (RajzSzerkesztő) 
— Együttműködik a Cél felületnek megfelelő objektumokkal. 
e Illesztendő (TextView) 
— Meghatároz egy már létező felületet, amelyet illeszteni kell. 
s Illesztő SzövegAlakzaD 
— Az lIllesztendő felületét a Cél felülethez illeszti. 


Együttműködés 


s Az Ügyfelek egy Illesztő példányra hívnak meg műveleteket, az illesztő pedig az II- 
lesztendő műveleteit hívja meg a kérelmek teljesítéséhez. 


Következmények 


Az osztály- és objektumillesztők előnyei és hátrányai különböznek. Az osztályillesztőkre 
a következők jellemzők: 


. Az llesztendőt egy konkrét Illesztendő osztályhoz ragaszkodva illesztik a Célhoz. 
Ennek következményeképpen az osztályillesztők nem működőképesek, amennyi- 
ben egy osztályt és annak minden alosztályát szeretnénk illeszteni. 

e Lehetővé teszik, hogy az Illesztő felülbírálja az Illesztendő néhány viselkedését, hi- 
szen az Illesztő az Illesztendő alosztálya. 

" Csak egy objektumot kell bevezetni, és az illesztendőhöz való eljutáshoz nincs szük- 
ség további mutatókra. 


Az objektumillesztőkkel kapcsolatban a következőket kell megjegyeznünk: 


e  Egyeten Illesztő több illesztendővel is működhet, vagyis magával az Illesztendővel, 
és annak minden alosztályával (ha vannak ilyenek). Az Illesztő emellett minden II- 
lesztendőt egyszerre bővíthet szolgáltatásokkal. 

, Az lllesztendő viselkedését nehezebb felülbírálni. Ehhez alosztályok származtatása 
szükséges az Illesztendő osztályból, az Illesztőnek pedig az alosztályokra kell hivat- 
koznia, nem pedig közvetlenül az Illesztendőre. 


Az Illesztő minta alkalmazásával kapcsolatban az alábbi kérdésekkel kell még foglalkoznunk: 
1. Mi mindent illeszt az Illesztő? Az illesztők eltérő mennyiségű munkát végezhetnek 


az Illesztendőnek a Cél felülethez való illesztéséhez. A lehetséges műveletek skálája 
az egyszerű felületátalakítástól (például a műveletek nevének megváltoztatásával) 


illesztő 
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a teljesen különböző művelethalmazok támogatásáig terjedhet. Az Illesztő által el- 
végzendő munka mennyisége attól függ, mennyire hasonlít a Cél és az Illesztendő 
felülete. 

.  Csatlakoztatható illesztők. Egy osztály jobban újrahasznosítható, ha a lehető legkeve- 
sebbre csökkentjük azon feltételezések számát, amelyekkel más osztályoknak élniük 
kell, ha az osztályt használni kívánják. Azzal, hogy a felületillesztést egy osztályba he- 
lyezzük, megszabadulunk a feltételezéstől, hogy a többi osztály ugyanazt a felületet 
látja. Más szavakkal, a felületillesztés lehetővé teszi, hogy osztályunkat olyan meglevő 
rendszerekbe építsük be, amelyek más felületet várhatnak az osztálytól. A beépített 
felületillesztéssel rendelkező osztályok leírására az ObjectWorksiSmalltalk [Par90] 
a csatlakozhatható illesztő (pluggable adapter) kifejezést használja. 

Vegyünk egy FaNézet (TreeDisplay) grafikus vezérlőt, amely faszerkezetek grafikus 
megjelenítésére képes. Ha ezt a vezérlőt kifejezetten egy adott alkalmazásban való 
használatra szánták, az általa megjelenített objektumoktól egy bizonyos felületet kö- 
vetelhet meg, mondjuk mindegyiknek a Fa (Tree) nevű elvont osztályból kell szár- 
maznia. Ha a FaNézetet újrahasznosíthatóbbá szeretnénk tenni (mondjuk egy hasz- 
nos vezérlőket tartalmazó elemkészletbe szeretnénk építeni), ez a követelmény 
ésszerűtlen. Az egyes alkalmazások a faszerkezetekre saját osztályokat határoznak 
meg, így nem szabad, hogy arra kényszerítsük őket, hogy a mi Fa elvont osztályun- 
kat használják, hiszen a különböző faszerkezetek felülete is különböző. 

Egy könyvtárhierarchiában a gyermekeket a SzerezAlkönyvtárak (GetSubdirec- 
tories) művelettel érhetjük el, míg egy öröklési hierarchiában a megfelelő művelet 
neve SzerezAlosztályok (GetSubclasses) lehet. Egy újrahasznosítható FaNézet vezér- 
lőnek mindkét típusú hierarchiát meg kell tudnia jeleníteni, akkor is, ha azok felüle- 
te különbözik. Tehát a FaNézetnek beépített felületillesztést kell tartalmaznia. 

A Megvalósítás részben a felületillesztés osztályokba építésére több megoldást is 
megvizsgálunk. 


3. Kétirányú illesztők használata az átlátszóság biztosítására. Az illesztőkkel kapcso- 


latban az egyik lehetséges gond, hogy nem minden ügyfél számára , átlátszók". Az il- 
lesztett objektumok többé nem felelnek meg az Illesztendő felületnek, így nem hasz- 
nálhatók bárhol, ahol az Illesztendő objektumok igen. A szükséges átlátszóságot 
a kétirányú illesztők biztosíthatják. Különösen akkor hasznosak, ha két ügyfélnek kü- 
lönbözőképpen kell látnia egy objektumot. 

Vegyünk egy kétirányú illesztőt, amely összekapcsolja a Unidraw grafikus szerkesztő 
keretrendszert [VL90], illetve a DOCA megszorításfeloldó elemkészletet IHHMV92]. 
Mindkét rendszer rendelkezik olyan osztályokkal, amelyek kifejezetten ábrázolnak 
változókat: a Unidraw-ban ilyen a StateVariable (ÁllapotVáltozó), a DOCA-ban pedig 
a ConstraintVariable (KötésVáltozó). Ahhoz, hogy a Unidraw együttműködhessen 
a OOCA-val, a ConstraintVariable-t a StateVariable felületéhez kell illeszteni, ahhoz 
pedig, hogy a OOCA nyújthasson megoldásokat a Unidraw-nak, a StateVariable kell, 
hogy igazodjon a ConstraintVariable felületéhez. 
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(a OOCA osztályhierarchiához) (a Unidraw osztályhierarchiához) 
1 [8 





StateVariable 











[/ Constraintstatevariable J 





A megoldás kulcsa a ConstraintStateVariable kétirányú osztályillesztő, amely mind 
a StateVariable, mind a ConstraintVariable alosztálya, feladata pedig a két felület egy- 
máshoz illesztése. A többszörös öröklés ebben az esetben megfelelő megoldás, mert 
az illesztett osztályok felülete jelentősen különbözik. A kétirányú osztályillesztő 
mindkét osztálynak megfelel, így mind a két rendszerben működik. 


Megvalósítás 
Bár az Illesztő minta megvalósítása általában elég egyértelmű, néhány dologra figyelnünk kell: 


1. Az osztályillesztők megvalósítása a Cs4-ban. Az osztályillesztők C4--- nyelvű megva- 


lósításában az Illesztő nyilvánosan örököl a Céltól, és privát módon az Illesztendőtől, 
így a Célnak altípusa, de az Illesztendőnek nem. 


.  Csatlakoztatható illesztők. Tekintsünk át három módszert a korábban bemutatott, hi- 


erarchikus szerkezeteket automatikusan megjeleníteni képes FaNézet (IreeDisplay) 
vezérlő csatlakoztatható illesztőinek megvalósítására. 
Az első lépés, ami közös az itt bemutatott mindhárom megvalósításban, az Illeszten- 
dő keskeny" felületének megtalálása, vagyis az illesztéshez szükséges legkisebb 
művelethalmaz meghatározása. Egy csak néhány műveletből álló keskeny felület 
könnyebben illeszthető, mint egy műveletek tucatjait tartalmazó. A FaNézet eseté- 
ben az illesztendő bármilyen hierarchikus szerkezet lehet. Az elképzelhető legki- 
sebb felület két műveletet tartalmaz: az egyik meghatározza, hogyan jeleníthetünk 
meg grafikusan egy csomópontot a hierarchiában, a másik pedig megkeresi a cso- 
mópont gyermekeit. 

A keskeny felülettel a megvalósításnak három megközelítése lehet: 

(a) Elvont műveletek használata. A FaNézet osztályban megfelelő elvont műveleteket 
határozunk meg a keskeny Illesztendő felület számára, Az alosztályoknak meg kell 
valósítaniuk ezeket az elvont műveleteket, és illeszteniük kell a hierarchikus szer- 
kezetű objektumot. Egy KönyvtárFaNézet (DirectoryTreeDisplay) nevű alosztály 
például a könyvtárszerkezet elérésével valósíthatja meg a műveleteket. 


























KönyvtárFaNézet (illesztő) 








SzerezGyermekek(Csomópont) 
LétrehozGrafikusCsomópont(Csomópont) , ———— me FájlgRendszerEgyed (illesztendő) 














(b) 





A KönyvtárFaNézet (DirectoryTreeDisplay) arra ,szakosítja" a keskeny felületet, 
hogy FájlRendszerEgyed (FileSytemEntity) objektumokból álló könyvtárszerke- 
zeteket jelenítsen meg. 

Képviselő objektumok használata. Ennél a megközelítésnél a FaNézet a hierar- 
chikus szerkezet elérésére irányuló kérelmeket egy képviselő (delegate) objek- 
tumnak továbbítja. A képviselő cseréjével a FaNézet különféle illesztési módsze- 
reket használhat. 

Tegyük fel például, hogy van egy KönyvtárTallózó (DirectoryBrowser) nevű ele- 
münk, amely a FaNézetet használja. A KönyvtárTallózó kiválóan megfelel képvi- 
selőnek, ha a FaNézetnek a hierarchikus könyvtárszerkezethez való illesztéséről 
van szó. A dinamikus típusokra épülő nyelvekben, amilyen a Smalltalk vagy az 
Objective C, ez a megközelítés csak egy, a képviselőt az illesztő számára bejegy- 
ző felületet igényel. Ezután a FaNézet egyszerűen továbbíthatja a kérelmeket 
a képviselőnek. A NEXTSTEP [IAdd94] gyakran él ezzel a megoldással az alosz- 
tályok számának csökkentése céljából. 

A C4-hoz hasonlóan statikus típusokkal dolgozó nyelvek kifejezett felület-meg- 
határozást követelnek meg a képviselő számára. Egy ilyen felületet úgy határoz- 
hatunk meg, hogy a FaNézet igényelte keskeny felületet egy elvont FaElérő- 
Képviselő (TreeAccessorDelegate) osztályba helyezzük. Ezt a felületet ezután 
örökléssel a kívánt képviselőbe (esetünkben a KönyvtárTallózóba) , keverhet- 
jük". Amennyiben a KönyvtárTallózónak nincs szülőosztálya, egyszeres örök- 
lést, ha van, többszörös öröklést használunk. Az osztályok ily módon történő 
összekeverése könnyebb, mint egy új FaNézet alosztály bevezetése és művelete- 
inek egyenkénti megvalósítása. 
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[2 FaElérőképviselő (Cél) 


SzerezGyermekekíFaNézet, Csomópont) 
LétrehozGrafikusCsomópont(FaNézet, Csomópont) 
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képviselő LétrehozGrafikusCsomópontíthis, gyermek) 
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FájlgendszerEgyed (illesztendő) 





Tzásis 





(c) Paraméteres illesztők. A csatlakoztatható illesztők támogatásának általános mód- 
ja a Smalltalkban, hogy az illesztőt egy vagy több blokkal paraméterezzük. 
A blokkszerkezet alosztályok létrehozása nélkül támogatja az illesztést. Az egyes 
blokkok kérelmeket illeszthetnek, az illesztő pedig minden kérelemhez egy-egy 
blokkot tárolhat. Példánkban ez azt jelenti, hogy a FaNézet egy blokkot tárol 
a csomópontok (Node) GrafikusCsomóponttá (GraphicNode) alakításához, egy 
másikat pedig a csomópont gyermekeinek eléréséhez. 
Egy könyvtárszerkezet fanézetének (TreeDisplay) elkészítéséhez például a kö- 
vetkező kódot írhatjuk: 


directoryDisplay :- 
(TreeDisplay on: treeRoot) 
getChildrenBlock: 


[:node I node getSubdirectories] 
createGraphicNodeBlock : 
[:node I] node createGraphicNodelj . 


Ha egy osztályba felületillesztést építünk be, ezzel a megközelítéssel kényelme- 
sen helyettesíthetjük az alosztályok létrehozását. 


Példakód 


Az alábbiakban rövid vázlatát nyújtjuk a Feladat részben bemutatott osztály- és objektumillesz- 
tők megvalósításának. Kezdjük a Shape (Alakza0) és Textview (SzövegNézet) osztályokkal: 


class Shape ( 
public 
Shape ( ) ; 
virtual void BoundingBox( 


Illesztő 
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Pointg bottomLeft, Point§ topRight 
) const; 
virtual Manipulatory CreateManipulator() const; 
pr 


class TextView ( 
public: 
TextView() ; 
void GetOrigin(Coord5s x, Coord5ő y) const; 
void GetExtent (Coord§ width, Coordg height) const; 
virtual bool IsEmpty() const; 
ha 


A Shape egy olyan befoglaló dobozt (bounding box) feltételez, amelyet ellentétes sarkai 
határoznak meg. A TextView-t ezzel szemben a kezdőpont (origin), a szélesség (width) és 
a magasság (height) írja le. A Shape ezenkívül meghatároz egy CreateManipulator 
(LétrehozMódosító) nevű műveletet is a Manipulator (Módosító) objektumok létrehozá- 
sára, amelyek tudják, hogyan kell mozgatni az alakzatokat a felhasználó tevékenységének 
megfelelően." A TextView nem rendelkezik hasonló művelettel. A Text Shape (Szöveg- 
Alakza0) osztály ezen különböző felületek illesztője. 


Az osztályillesztők többszörös örökléssel illesztik a felületeket. Működésük kulcsát az jelen- 
ti, hogy külön öröklési ágon öröklik a felületet, illetve a megvalósítást. E különbségtétel 
a Ctt-ban általában úgy jelenik meg, hogy a felületet nyilvánosan, míg a megvalósítást pri- 
vát módon örököljük. A TextShape illesztőt ennek a hagyománynak megfelelően határoz- 
zuk meg. 


class TextShape : public Shape, private TextView ( 
public: 
TextShape ( ) ; 


virtual void BoundingBox( 
Pointg bottomLeft, Point§ topRight 
) const; 
virtual bool IsEmpty() const; 
virtual Manipulatort CreateManipulator() const; 
1; 


A BoundingBox művelet a TextView felületének átalakítását végzi, hogy az megfeleljen 
a Shape-ének. 


void TextShape:  :BoundingBox ( 

Point§g bottomLeft, Pointg topRight 
) cönst ( 

Coord bottom, left, width, height; 





! A CreateManipulator a Gyártófüggvény példája. 
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GetOrigin(bottom, left); 
GetExtent (width, height); 


bottomLefít - Point(bottom, left); 
topRight - Point(bottom 4 height, left 4 width); 
) 


Az IsEmpty (Üres) művelet az illesztők megvalósításában gyakori megoldást, a kérelmek 
közvetlen továbbítását mutatja be: 


bool TextShape: :IsEmpty() const ( 
return TextView: : IsEmpty ( ) ; 
) 


Végezetül meghatározzuk a CreateManipulator-t (amelyet a TextView nem támoga0; 
ezt teljes egészében nekünk kell megtennünk. Tegyük fel, hogy már megvalósítottunk egy 
TextManipulator nevű osztályt, ami a TextShape objektumok kezelésére szolgál. 


Manipulatorr TextShape: : reateManipulator () const ( 
return new TextManipulatoríthis); 


§ 


Az objektumillesztő objektum-összetétellel illeszti egymáshoz a különböző felületű osztá- 


lyokat. Ennél a megközelítésnél a Text Shape illesztő egy mutatóval rendelkezik a Text - 
View-ra, 


class TextShape : public Shape ( 
public: 
TextShape ( TextViewt ) ; 


virtual void BoundingBox( 
Pointg bottomLeft, Pointá topRight 

) const; 

virtual bool IsEmpty() const; 

virtual Manipulatort CreateManipulator() const; 
private: 

TextViewt — text; 
1; 


A TextShape-nek a TextvView példányra kell állítania a mutatót; ezt a konstruktorban 
meg is teszi. Emellett minden esetben, amikor műveleteit hívják, TextView objektumára is 
meg kell hívnia a műveleteket. A példában feltételezzük, hogy az ügyfél létrehozza 
a TextView objektumot, és átadja azt a Text Shape konstruktorának: 


TextShap TextShape (TextViewt t) ( 
—töxt - t 





, 


illesztő 
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void TextShape: :BoundingBox ( 

Póintg bottomLefít, Pointg£ topRight 
) const ( 

Coord bottom, left, width, height; 


.-text-osGetOrigin(bottom, left); 
.-text-:GetExtent(width, height); 


bottomLeft - Point(bottom, left); 
topRight - Point(bottom 4 height, left 14 width); 


bool TextShape::IsEmpty () const ( 
return . text—IsEmpty ( ) ; 
) 


A CreateManipulator megvalósítása nem különbözik az osztályváltozatnál látottól, hi- 
szen mi készítettük el a semmiből, a Textview szolgáltatásaiból semmit sem használ. 


Manipulatort TextShape::CreateManipulator () const ( 
return new TextManipulatoríthis) ; 


) 


Hasonlítsuk össze a kódot az osztályillesztőével, és meglátjuk, az objektumillesztő megírá- 
sa ugyan valamivel több munkát igényel, de rugalmasabb. A TextShape objektumillesztő 
változata például a Textview alosztályaival is jól működik: az ügyfél egyszerűen átadja 
a TextShape konstruktorának a megfelelő alosztály egy példányát. 


Ismert felhasználások 


A Feladat részben látott példa az ET4--Draw rajzolóprogramból származik, amely az ET4-t- 
ra épül IWGM8AgI. A program az ET1- osztályok szövegszerkesztésre való újrahasznosításá- 
hoz egy TextShape nevű illesztőosztályt használ. 


Az InterViews 2.6 egy Interactor nevű elvont osztályt tartalmaz az olyan felhasználói felüle- 
ti elemekhez, mint a gördítősávok, a gombok, vagy a menük ÍVL88]. Emellett egy Graphic 
nevű elvont osztályt is meghatároz az olyan strukturált grafikus objektumokhoz, mint a vo- 
nalak, körök, sokszögek és görbék. Mind az Interactor, mind a Graphic rendelkeznek grafi- 
kus megjelenéssel, de felületük és megvalósításuk különböző (nem osztoznak közös szülő- 
osztályon), így nem összeegyeztethetők, vagyis egy strukturált grafikus objektum nem 
ágyazható be közvetlenül mondjuk egy párbeszédablakba. 


Ehelyett az InterViews 2.6 egy GraphicBlock (GrafikusBlokk) nevű objektumillesztőt hatá- 
roz meg, amely az Interactor alosztálya és egy Graphic példányt tartalmaz. A GraphicBlock 
illeszti a Graphic osztály felületét az Interactoréhoz, és a Graphic példányok ennek segítsé- 
gével jeleníthetők meg, görgethetők és nagyíthatók egy Interactor szerkezeten belül. 
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A csatlakoztatható illesztők általánosak az ObjectWorksi Smalltalk-ban [Par90]. A szabványos 
Smalltalk egy ValueModel (ÉrtékModelD nevű osztályt határoz meg az egyetlen értéket meg- 
jelenítő nézetek számára. Az érték elérésére a ValueModel a value, value: elvont mető- 
dusokból álló felületet biztosítja. Az alkalmazáskészítők erre a célra olyan, az adott tarto- 
mányra jellemzőbb neveket használhatnak, mint a width és a width:, de nem szabad, 
hogy ezeket úgy illesszék a ValueModel felülethez, hogy a ValueModel-ből alosztályokat 
származtatnak. 


Az ObjectWorksvSmalltalk ehelyett a ValueModel PluggableAdaptor (Csatlakoztatható- 
Illesztő) alosztályát alkalmazza. A PluggableAdaptor objektumok más objektumokat illesz- 
tenek a ValueModel felületéhez (value, value : ), a kívánt értékek beállításához és lekér- 
dezéséhez pedig blokkokkal paraméterezhetők; a PluggableAdaptor belsőleg ezekkel 
a blokkokkal valósítja meg a value, value: felületet. Az alosztály emellett azt is lehetővé 
teszi, hogy a kényelmesebb nyelvi megfogalmazás érdekében közvetlenül adjuk át a sze- 
lektorneveket (pl. width, width:). A szelektorok megfelelő blokkokká átalakítása auto- 


matikusan történik. 
ValueModel 


value: 
value 
LN 


PluggableAdaptor 









illesztendő 















value: 
ÁTELLENES Öreséezéees azza 


glésáka; ! " getBlock value: illesztendő 


getBlock 
setBlock 


Egy másik példa az ObjectWorkstSmalltalkból a TableAdaptor (Táblázatillesztő) osztály, 
amely objektumsorozatokat illeszt egy táblázatos megjelenítéshez. A táblázat soronként egy 
objektumot jelenít meg. Az ügyfél a TableAdaptornak paraméterként azt az üzenethalmazt ad- 
ja át, amelynek segítségével a táblázatok lekérdezhetik az oszlopértékeket az objektumoktól. 


A NEXT AppkKit-jének (Add94] néhány osztálya képviselő objektumokkal hajt végre felület- 
illesztést. Ennek egyik példája az NXBrowser (NXTallózó) osztály, amely adatok hierarchi- 
kus listájának megjelenítésére képes. Az NXBrowser egy képviselő objektummal éri el és il- 
leszti az adatokat. 


Híd 
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Meyer , kényelmi házassága" (Marriage of Convenience) [IMey88] szintén egyfajta osztályil- 
lesztő. Meyer leírja, hogyan illeszti egy FixedStack (RögzítettVerem) nevű osztály egy Array 


(Tömb) osztály megvalósítását egy Stack (Verem) osztály felületéhez. Az eredmény egy ve- 
rem, amely rögzített számú elemet tartalmaz. 


Kapcsolódó minták 


A hidak (ásd: Híd minta) szerkezete hasonló az objektumillesztőkéhez, de céljuk más: arra 
valók, hogy egy felületet elválasszunk a megvalósításától, hogy azok könnyen és egymástól 
függetlenül módosíthatók legyenek. Az illesztők ezzel szemben egy meglevő objektum fe- 
lületét változtatják meg. 


A Díszítő mintában anélkül bővítünk ki egy másik objektumot, hogy megváltoztatnánk an- 
nak felületét. A díszítők így ,átlárszóbbak" az alkalmazás számára, mint az illesztők, amiből 
az is következik, hogy a Díszítő minta támogatja az önhívó összetételt, ami a tiszta illesztők- 
kel nem lehetséges. 


A Helyettes minta képviselőt vagy helyettesítőt biztosít egy másik objektum számára, de 
nem változtatja meg annak felületét. 


Híd 
Szerkezeti objektumminta 
Cél 


Az elvont ábrázolást elválasztani a megvalósítástól, hogy a kettő egymástól függetlenül mó- 
dosítható legyen. 


Egyéb nevek 


Bridge, Handle/Body (Leíró/Törzs) 


Feladat 


Amikor egy elvont fogalomhoz több lehetséges megvalósítás közül választhatunk egyet, 
a megvalósításokat általában örökléssel készítjük el. Egy elvont osztály határozza meg a fe- 
lületet, amit a konkrét alosztályok különbözőképpen valósítanak meg. Ez a megközelítés 
azonban nem mindig kellőképpen rugalmas. Az öröklés maradandó kötést hoz létre az el- 
vont fogalom és a megvalósítás között, ami megnehezíti azok egymástól független módosí- 


tását, bővítését és újrahasznosítását. 
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Vegyük például egy rendszerek között hordozható Ablak (Window) megvalósítását egy fel- 
használói felületi elemkészletben. Az elvont ábrázolásnak lehetővé kell tennie, hogy olyan al- 
kalmazásokat írhassunk, amelyek mind az X Window System, mind az IBM Presentation Ma- 
nager (PM) felületén működnek. Örökléssel meghatározhatunk egy Ablak nevű elvont osz- 
tályt, amelynek XAblak (XWindow) és PMAblak (PMWindow) alosztályai valósítják meg az 
Ablak felületet a különböző rendszerek számára. Ennek a megoldásnak két hátulütője van: 


1. Az elvont Ablak bővítése más ablaktípusok vagy új rendszerek támogatásához ké- 
nyelmetlen. Képzeljük el az Ablak IkonAblak (IconWindow) nevű alosztályát, amely 
az Ablak fogalmát ikonokra terjeszti ki. Ahhoz, hogy az IkonAblak támogatása mind- 
két rendszerre megoldott legyen, két új osztályt — XIkonAblak (XIconWindow) és 
PMIkonAblak (PMIconWindow) — kell megvalósítanunk. Ami még ennél is rosszabb, 
minden ablaktípusra két osztályt kell meghatároznunk, egy harmadik rendszer támo- 
gatása pedig újabb Ablak alosztályok készítését igényli a különféle ablaktípusokhoz,. 


Ablak 
] 


XAblak PMAblak XAblak ] [ PMAblak IkonAblak 


en tini 


XikonAblak  ] [ PMikonAblak 






























































2. Az ügyfél kódját rendszerfüggővé teszi. Amikor az ügyfél létrehoz egy ablakot, egy 

adott megvalósítással rendelkező konkrét osztályt példányosít. Egy XAblak objek- 
tum létrehozásakor például az X Window megvalósításhoz kötjük az Ablak fogalmát, 
aminek eredményeképp az ügyfél kódja ettől a megvalósítástól fog függni, és nehéz 
lesz azt más rendszerekre átültetni. 
Az ügyfeleknek képesnek kell lenniük arra, hogy anélkül hozzanak létre egy abla- 
kot, hogy egy bizonyos megvalósításhoz ragaszkodnának. Kizárólag az ablak meg- 
valósításának szabad függnie a rendszertől, amelyen az alkalmazás fut. Mindebből 
az következik, hogy az ügyfélkódnak az ablakok példányosítását rendszerfügget- 
lenül kell végeznie. 





A Híd tervezési minta úgy oldja meg ezt a problémát, hogy az Ablak fogalmát és annak 
megvalósítását külön osztályhierarchiákba helyezi. Egy osztályhierarchia ábrázolja az ab- 
lakfelületeket (Ablak, IkonAblak, ÁtmenetiAblak), egy másik, önálló hierarchia pedig az 
egyes rendszerekhez nyújtott ablak-megvalósításokat, amelynek gyökere az AblakMeg- 
valósítás (Windowlmp). Az XAblakMegvalósítás (XWindowlmp) alosztály például az 
X Window System alapú megvalósítást biztosítja. 
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Az Ablak alo 
műveletei ala 






ályokon végzett valamennyi műveletet az AblakMegvalósítás felület elvont 
pján valósítjuk meg, így elválasztjuk az elvont ábrázolást a különböző rend- 
szerfüggő megvalósításoktól. Az Ablak és az AblakMegvalósítás közötti kapcsolat a híd, 
amelyen keresztül az elvont fogalom és megvalósítása egymáshoz kapcsolódik, és amely 
azok egymástól független módosítását lehetővé teszi. 


Alkalmazhatóság 


A Híd minta használata a következő esetekben célszerű: 


e El szeretnénk kerülni az elvont fogalom és megvalósítása közti maradandó kötést. 
Erre akkor lehet például szükség, ha futásidőben kell választani a megvalósítások 
közül, vagy átkapcsolni közöttük. 

e Mind az elvont ábrázolásnak, mind a megvalósításnak bővíthetőnek kell lennie al- 
osztályok származtatásával. A Híd minta lehetővé teszi a különböző elvont fogalmak 
és megvalósítások párosítását és egymástól független bővítését. 

e Az elvont ábrázolás megvalósításában eszközölt változásoknak nem szabad hatással 
lenniük az ügyfelekre, vagyis nem igényelhetik azok kódjának újrafordítását. 

e (Ct4) Egy fogalom megvalósítását teljesen el kívánjuk rejteni az ügyfelek elől. 
A Ct4-ban az osztályok ábrázolása látható az osztály felületében. 
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s Túl sok osztály jött létre, mint a Feladat részben található első diagramon láttuk. 
Az ilyen osztályhierarchia annak szükségességére világít rá, hogy egy adott objektu- 
mot két részre kell vágnunk. Rumbaugh a ,beágyazott általánosítások" (nested 
generalizations) kifejezést használja az ilyen hierarchiákra IRBP--91]. 

e Meg szeretnénk osztani egy megvalósítást több objektum között (mondjuk hivatko- 
Zás-számlálással), és ezt el szeretnénk rejteni az ügyfél elől. Ennek egyszerű példája 
Coplien String osztálya [Cop92], ahol több objektum osztozhat ugyanazon a karak- 
terlánc ábrázoláson (StringRep). 


Szerkezet 





megvalósítás 





ElvontÁbrázolás Megvalósító 


VAX 





FinomítottElvontÁbrázolási ! KonkrétMegvalósítóA j KonkrétMegvalósítóB ] 
[ MűveletMegvalósítésű ] MűveletMegvalósítás() ] 

















Résztvevők 


e  ElvontÁbrázolás (Ablak) 
— Meghatározza az elvont fogalom felületét. 
— Egy Megvalósító típusú objektumra hivatkozik. 
e  FinomítottElvontÁbrázolás (IkonAblak) 
— Kibővíti az Elvontábrázolás által meghatározott felületet. 
e  Megvalósító (AblakMegvalósítás) 
— Meghatározza a megvalósító osztályok felületét. E felületnek nem kell pontosan 
megfelelnie az Elvontábrázolás felületének, sőt, a kettő teljesen különböző is lehet. 
A Megvalósító felület általában csak alapműveleteket nyújt, míg az Elvontábrázolás 
magasabb szintű műveleteket határoz meg, amelyek ezeken az alapműveleteken 
alapulnak. 
s  KonkrétMegvalósító (XAblakMegvalósítás, PMAblakMegvalósítás) 
— Megvalósítja a Megvalósító felületet, és meghatározza annak konkrét megvalósítását. 
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Együttműködés 


s Az ElvontÁbrázolás (Abstraction) továbbítja az ügyfél kérelmeit a hozzá tartozó Meg- 
valósító (Implementor) objektumhoz. 


Következmények 


A Híd minta előnyei a következők: 


1. A felület és a megvalósítás szétválasztása. A megvalósítások nem kötődnek maradan- 
dóan a felülethez, és futásidőben beállíthatók. Még az is lehetséges, hogy egy objek- 
tum futás közben változtassa meg a megvalósítását. 

Az ElvontÁbrázolás és a Megvalósító szétválasztása a fordítási idejű megvalósítás- 
függőséget is megszünteti. A megvalósító osztály megváltoztatása nem igényli az 
Elvontábrázolás osztály és ügyfelei újrafordítását, ami létfontosságú, ha egy osztály- 
könyvtár különböző változatai között biztosítanunk kell a bináris megfelelőséget. 
Emellett ez a szétválasztás rétegezésre buzdít, aminek eredménye egy jobban szer- 
vezett rendszer lehet. A rendszer magas szintű részének csak az ElvontÁbrázolás és 
a Megvalósító osztályokat kell ismernie. 

2. Jobb bővíthetőség. Az Elvontábrázolás és Megvalósító hierarchiák egymástól függet- 
lenül bővíthetők. 

3. A megvalósítás részleteinek elrejtése az ügyfelek elől. Az ügyfeleket elzárhatjuk 
a megvalósítás olyan részletei elől, mint amilyen a megvalósító objektumok megosz- 
tása és az ahhoz kapcsolódó hivatkozás-számlálás (ha van ilyen). 


Megvalósítás 


A Híd minta megvalósításával kapcsolatban a következő dolgok lényegesek: 


1. Csak egy Megvalósító. Az olyan helyzetekben, amikor csak egyetlen megvalósítás lé- 

tezik, az elvont Megvalósító osztály létrehozása nem szükséges. Ez a Híd minta , s0- 
vány" változata; az ElvontÁbrázolás és a Megvalósító között ekkor egy az egyhez 
kapcsolat áll fenn. A szétválasztás azonban akkor is hasznos, ha egy osztály megva- 
lósításának módosítása nem szabad, hogy hatással legyen az osztály meglevő ügyfe- 
leire, vagyis hogy azokat újrafordítani ne kelljen, csak újra beszerkeszteni. 
Carolan ICar89] erre a fajta szétválasztásra a , Cheshire Cat" elnevezést használja. 
A C44-ban a Megvalósító osztályfelülete egy olyan privát fejléc-állományban hatá- 
rozható meg, amelyet az ügyfelek nem kapnak meg, így az osztályok megvalósítása 
teljesen elrejthető az ügyfelek elől. 

2. A megfelelő Megvalósító objektum létrehozása. Ha egynél több van belőlük, hogyan, 
hol és mikor döntjük el, melyik Megvalósító osztályt kell példányosítani? 

Ha az ElvontáÁbrázolás valamennyi KonkrétMegvalósító (Concretelmplementor) osz- 
tályt ismeri, konstruktorában példányosíthatja egyiküket, és a konstruktornak át- 
adott paraméterek alapján választhat közülük. Ha egy gyűjteményosztály például 
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több megvalósítást is támogat, a döntés meghozható a gyűjtemény mérete alapján. 
A kisebb gyűjteményekhez használhatunk egy láncolt lista alapú megvalósítást, míg 
a nagyobbakhoz egy hasító- vagy kivonattáblát (hash). 

Egy másik megközelítés, ha kezdetben megadunk egy alapértelmezett megvalósí- 
tást, és később igény szerint módosítjuk. Például ha a gyűjtemény növekedése köz- 
ben túllép egy bizonyos küszöböt, megvalósítását a nagyobb számú elemnek megfe- 
lelőre cserélheti. 

A döntés teljes egészében át is ruházható egy másik objektumra. Az Ablak—Ablak- 
Megvalósítás példában mondjuk bevezethetünk egy gyár objektumot (lásd az Elvont 
gyár mintát a 3. fejezetben), amelynek egyetlen feladata a rendszerfüggő jellemzők 
egységbe zárása. A gyár tudja, milyen típusú AblakMegvalósítás objektumot kell lét- 
rehozni az éppen használt rendszeren, így amikor egy Ablak ilyet kér tőle, a megfe- 
lelőt adja vissza. E megközelítés előnye, hogy az ElvontÁbrázolás egyik Megvalósító 
osztályhoz sem kötődik közvetlenül. 

3. A megvalósítók megosztása. Coplien [Cop92] bemutatja, hogy a C--4 leíró-törzs 
(Handle/Body) idiómája hogyan használható a megvalósítások több objektum kö- 
zötti megosztására, A törzs (Body) egy hivatkozásszámlálót tartalmaz, amelynek ér- 
tékét a leíró (a Handle osztály) növeli vagy csökkenti. A megosztott törzsű leírók 
hozzárendelési kódjának általános alakja a következő: 

Handleg Handle::operator- (const Handleg other) ( 
other. body-5Ref(); 
.body-sUnret ( ) ; 


if ( body-sRefCount() -- 0) ( 
delete body; 

h 

-body - other. body; 


rétüen VtHiss 





4. Többszörös öröklés használata. A C44-ban egy felületet többszörös örökléssel is 
összekapcsolhatunk a megvalósításával IMar91]. Egy osztály például örökölhet nyil- 
vánosan az Elvontábrázolás (Abstraction) osztálytól és privát módon egy Konkrét- 
Megvalósítótól. Ez a megoldás azonban statikus öröklésen alapul, ezért a megvalósí- 
tást maradandóan a felülethez köti. Ez az oka annak, hogy egy valódi Híd mintát nem 
valósíthatunk meg többszörös öröklés segítségével — legalábbis a C--4-ban nem. 
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Példakód 


Az alább bemutatott C$t- kód a Feladat részben bemutatott Ablak-AblakMegvalósítás 
(Window-Windowlmp) példát valósítja meg. A Window (Ablak) osztály az ablak fogalmát 
határozza meg az ügyfélprogramok számára: 


class Window ( 
public: 
Window(Viewt contents); 


//az ablak által kezelt kérelmek 
virtual void DrawContents-( ) ; 


virtual void Open() ; 
virtual void Close(); 
virtual void Iconify(); 
virtual void Deiconify(); 


// a megvalósításhoz továbbított kérelmek 
virtual void SetOrigin(const Pointő§ at); 
virtual void SetExtent(const Pointg§ extent); 
virtual void Raise(); 

virtual void Lower (); 


virtual void DrawLine(const Pointg, const Pointf6); 
virtual void DrawRect(const Pointg, const Pointf£); 
virtual void DrawPolygon(const Point[], int n); 
virtual void DrawText(const char, const Point6); 


protected: 
WindowImp" GetWindowImp () ; 
Viewt GetView(); 


private: 
WindowImpt . imp; 
Viewt "contents; // az ablak tartalma 


hi 


A Window egy WindowImp-re (AblakMegvalósítás) hivatkozik, amely a háttérben megbúvó 
ablakkezelő rendszerhez felületet bevezető elvont osztály. 


class Windowimp ( 


public: 
virtual void ImpTop() - 0; 
virtual void ImpBottom() - 0; 
virtual void ImpSetExtent(const Point5) - 0; 


virtual void ImpSetOrigin(const Pointf£) 


1 
o 
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virtual void DeviceRect(Coord, Coord, Coord, Coord) - 0; 

virtual void DeviceText (const char", Coord, Coord) - 0; 

virtual void DeviceBitmap(const char", Coord, Coord) - 

// számos további függvény az ablakra rajzoláshoz... 
protected: 


WindowImp ( ) ; 


07 


1; 


Az alkalmazás által használható ablakfajtákat — ablakok, ikonok, párbeszédablakok (átme- 
neti ablakok, TransientWindow), lebegő eszközpaletták stb. — a Window alosztályai hatá- 
rozzák meg. 


Az ApplicationWindow (AlkalmazásAblak) például a Drawcontents (RajzolTartalom) 
műveletet valósítja meg, ami a tárolt View (Nézet) példányt rajzolja meg: 


class ApplicationWindow : public Window ( 
public: 

9 ALA 

virtual void DrawContents( ) ; 
1; 


void ApplicationWindow: :DrawContents () ( 
GetView( ) oDrawOn(this) ; 
) 


Az IconWindow (IkonAblak) az általa megjelenítendő ikon bitképének nevét tárolja... 


class IconWindow : public Window ( 
public: 

EZáréss 

virtual void DrawContents( ) ; 
private: 

const chart  bitmapName; 
); 


:.És a DrawContents-t úgy valósítja meg, hogy az kirajzolja a bitképet az ablakban: 


void IconWindow: :DrawContents() ( 
WindowImpt imp - GetWindowImp( ) ; 
if l(imp !z 0) (í 
imp-sDeviceBitmap( bitmapName, 0.0, 0.0); 
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A Window-nak számos további változata lehetséges. Egy TransientWindow-nak (átmeneti 
ablak, párbeszédablak) működés közben szüksége lehet arra, hogy kapcsolatba lépjen azzal 
az ablakkal, amelyik létrehozta, ezért hivatkozást tárol rá. A paletták (PalettewWindow) min- 
dig más ablakok felett lebegnek, az ikontárolók (IconDockWindow) pedig IconWindow-kat 
tárolnak, és szépen elrendezik azokat. 


A Window műveletei a WindowImp felületen alapulnak. A DrawRect (RajzolTéglalap) pél- 
dául négy koordinátát számít ki két Point (Pont) paraméteréből, mielőtt meghívná a tégla- 
lapot az ablakban kirajzoló WindowImp-műveletet: 


void Window: :DrawRect (const Pointg pl, const Pointő p2) ( 
WindowImpt imp - GetWindowImp( ) ; 
imp-sDeviceRect(pl1.X(), pl.Y(), p2.X(), p2.Y()); 

) 


A WindowImp konkrét alosztályai különböző ablakkezelő rendszereket támogatnak; az 
XWindowImp alosztály például az X Window rendszert: 


class XWindowImp : public WindowImp ( 
public: 
XWindowImp ( ) ; 


virtual void DeviceRect(Coord, Coord, Coord, Coord) ; 
7// a nyilvános felület többi része... 

private: 
// X Window rendszerre jellemző állapotok, például: 
Displayt  dpy; 
Drawable  winid; 7// ablakazonosító 
GC Gé; 7/ ablakkörnyezet 

$$ 


A Presentation Manager (PM) esetében a PMWindowImp osztályt határozzuk meg: 


class PMWindowImp : public WindowImp ( 
public: 
PMWindowImp ( ) ; 
virtual void DeviceRect(Coord, Coord, Coord, Coord) ; 


// a nyilvános felület többi része... 
private: 
// PM rendszerre jellemző állapotok, például: 
HPS  hps; 
ty 
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Ezek az alosztályok a WindowImp műveleteit az adott ablakkezelő rendszer alapműveletei- 
re építve valósítják meg. A DeviceRect (EszközTéglalap) X alapú megvalósítása például 
a következő: 


void XWindowlImp: :DeviceRect ( 
Coord x0, Coord yO, Coord x1, Coord y1 
1 1 
int x - round(min(x0, x1)); 
int y - round(min(y0, y1)); 
int w - round(abs(x0 - x1)); 
int h - round(abs(yo0 - y1)); 
XDrawRectangle( dpy, . winid, gc, x, y, w, h); 


A PM megvalósítás formája az alábbi lehet: 


void PMWindowlImp::DeviceRect ( 

Coord x0, Coord yO, Coord x1, Coord y1 
) ( 

Coord left - min(x0O, x1); 

Cöoörd right - max(x0, x1); 

Coord bottom - min(y0, y1); 

Coord top - max(yO, y1); 


PPOINTL point[4]; 


point[0].x - left; point[0].y - top; 
point[1].x - right; point[(1].y - top; 
point[2].x - right; point[2].y - bottom; 
point[3].x - left; poóint[3].y - bottom; 
SE 1 
(GpiBeginPath( hps, 1L) -- false) II 
(GpiSetCurrentPosition( hps, ápoint[3]) -- false) II 
(GpiPolyLine( hps, 4L, point) -- GPI ERROR) II 
(GpiEndPath( hps) -- false) 
d § 
7/ hibaüzenet 
) else ( 


GpiStrokePath( hps, 1L, OL); 
ft 


Híd 





163 





Hogyan szerzik meg az ablakok a megfelelő WindowImp alosztály példányát? A példában 
feltesszük, hogy ez a Window felelőssége. Az osztály GetWindowImp (SzerezAblak- 
Megvalósítás) művelete egy, az ablakkezelő rendszer jellemzőit egységbe záró elvont gyár- 
tól (lásd az Elvont gyár mintát a 3. fejezetben) kéri el a megfelelő példányt. 


WindowImp" Window::GetWindowlImp () ( 
it 4.dmm sz 3 gé 
.-imp - WindowSystemFactory : : Instance ( )sMakeWindowImp ( ) ; 
d 
return . imp; 


ji 


A WindowgystemFactory : : Instance ( ) egy elvont gyárat ad vissza, amely az ablakke- 
zelő rendszerre jellemző objektumokat készíti el. Az egyszerűség kedvéért egykévé tettük 
(az Egyke mintát lásd az előző fejezetben), a Window osztálynak pedig megengedtük, hogy 
közvetlenül érje el a gyárat. 


Ismert felhasználások 


Az ablakos példa az ET--4-ból IWGM88] származik. Az ET----ban az AblakMegvalósítást 
, WindowPort"-nak hívják, amelynek olyan alosztályai vannak, mint az XWindowPort és 
a SunWindowPort. Az Ablak (Window) objektum a neki megfelelő Megvalósító (Imple- 
mentor) objektumot úgy hozza létre, hogy egy , WindowSystem" nevű elvont gyártól kéri 
el. A WindowSystem biztosítja az olyan rendszerfüggő objektumok létrehozásának felüle- 
tét, mint a betűtípusok, egérmutatók, bitképek és így tovább. 





Az ET44 Window-WindowPort megoldása annyiban bővíti a Híd mintát, hogy a WindowPort 
visszafelé, a Window-ra is hivatkozik. A WindowPort-megvalósító osztály ezt a hivatkozást 
arra használja, hogy értesítse a Window-t a WindowPort-ra jellemző eseményekről (a felhasz- 
nálói műveletekről, az ablakok átméretezéséről stb.). 


Coplien [Cop92] és Stroustrup IStr91] is megemlíti a leíró (Handle) osztályokat, és példákat is 
adnak. Ezek a példák a memóriakezelésre, például a karakterláncos ábrázolások megosztá- 
sára, illetve a változó méretű objektumok támogatására fektetik a hangsúlyt. Mi inkább az el- 
vont fogalom és megvalósítása egymástól független bővíthetőségére összpontosítottunk. 


A libg4- könyvtár [Lea88] olyan osztályokat határoz meg, amelyek általános adatszerkezete- 
ket (például Set, LinkedSet, HashSet, LinkedList, HashTable) valósítanak meg. A Set a hal- 
maz fogalmát meghatározó elvont osztály, míg a LinkedList és a HashTable a láncolt listák, 
illetve a hasító- vagy kivonattáblák konkrét megvalósítói. A LinkedSet és a HashSet olyan 
Set-megvalósítók, amelyek hidat képeznek az elvont Set és a konkrét LinkedList, illetve 
HashTable között. Ez a ,keskeny" híd példája, mivel nincs benne elvont Megvalósító osztály. 
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A NeXT AppkKit-je IAdd94] a grafikus képek megvalósításához és megjelenítéséhez használ- 
ja a Híd mintát. Egy kép többféleképpen is megjeleníthető; optimális megjelenítése a kép- 
ernyő tulajdonságaitól függ, különösképpen a színmegjelenítő képességektől, illetve a fel- 
bontástól. Az AppKit segítsége nélkül a fejlesztőknek kellene megállapítaniuk, melyik meg- 
valósítás használandó az egyes programokban, különböző körülmények között, 


Az AppKit az NXImage-NXImageRep híddal mentesíti ez alól a fejlesztőket. Az NXImage 
(NXKép) a képek kezelésének felületét írja le, míg a képek megvalósítását az önálló 
NXImageRep (NXKépÁDbr) osztályhierarchia határozza meg, amelyben olyan alosztályokat 
találunk, mint az NXEPSImageRep, az NXCachedilmageRep vagy az NXBitMaplmageRep. 
Az NXImage hivatkozást tart fenn egy vagy több NXImageRep objektumra. Ha egynél több 
képmegvalósítás létezik, az NXImage kiválasztja az aktuális képernyőnek legjobban megfe- 
lelőt. Az NXImage még arra is képes, hogy egy megvalósítást szükség esetén átalakítson egy 
másikká. E hídváltozat érdekes jellemzője, hogy az NXImage egyidőben több NXImageRep 
megvalósítást is tárolhat. 


Kapcsolódó minták 


Hidat létrehozhatunk és beállíthatunk elvont gyárral is. 


Az Illesztő minta lényege az egymással kapcsolatban nem álló osztályok együttműködésé- 
nek biztosítása. Általában olyan rendszerekben használják, amelyek már készen vannak. 
Ezzel szemben a Híd minta alkalmazása a tervezés elején történik, hogy lehetővé tegyük az 
elvont fogalmak és a megvalósítások egymástól független változtatását. 
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Összetétel 


Szerkezeti objektumminta 


Egyéb nevek 


Composite, Kompozit, Kompozíció, Összetett 
f4 
Cél 


Objektumokat faszerkezetbe rendezni, hogy ábrázolhassuk a rész—egész viszonyokat. A mód- 
szer révén az önálló objektumokat és az objektum-összetételeket egységesen kezelhetjük. 


Feladat 


Az olyan grafikus alkalmazások, mint a rajzolóprogramok és sémarögzítő rendszerek lehe- 
tővé teszik a felhasználóknak, hogy egyszerű alapelemekből bonyolult diagramokat építse- 
nek. Az elemek nagyobb elemekbe csoportosíthatók, amelyekből még nagyobb elemek 
hozhatók létre. Egy egyszerű megvalósításban ehhez meghatározhatjuk a grafikai alapele- 
mek (primitívek) olyan osztályait, mint a Szöveg (TexD) és a Vonal (Line), illetve azon osztá- 
lyokat, amelyek ezen alapelemek tárolóiként szolgálnak. 


Ezzel a megközelítéssel azonban van egy gond: az említett osztályokra épülő kódnak az 
alapelemeket és a tároló objektumokat különbözőképpen kell kezelnie, még akkor is, ha 
a felhasználó többnyire azonos módon bánik velük, az objektumok ezen megkülönbözte- 
tésének szükségessége pedig bonyolultabbá teszi az alkalmazást. Az Összetétel minta azt 
írja le, hogyan használhatunk önhívó összetételt (rekurzív kompozíción), hogy az ügyfél- 
programoknak ne kelljen ezzel a megkülönböztetéssel élniük. 





Grafika 


Rajzol() 
HozzáadíGrafika) 


Eltávolít(Grafika) 
SzerezGyermekfint) 


Vonal ] ( Tégtalap ] si mi kész 


Rajzol() Rajzol!) ] Rajzol() Új Rajzoll) 0-—————fessesszsssse öle: ét 788 


Etávolt(Grafika) : 
SzerezGyermekí(int) sé 1 hozzáad g to grafikák listája sg 
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Az Összetétel minta kulcsa egy elvont osztály, amely egyszerre ábrázolja az alapelemeket és 
tárolóikat. Az ábrán látható grafikai rendszerben ez az osztály a Grafika (Graphic). A Grafi- 
ka a Rajzol-hoz (Draw) hasonló műveleteket vezet be, amelyek az egyes grafikus objektu- 
mokra jellemzőek, illetve olyan műveleteket, amelyeket az összetett objektumok közösen 
használnak, például gyermekeik elérésére és kezelésére. 


A Vonal, Téglalap és Szöveg (Line, Rectangle, Text) alosztályok (lásd az előző osztálydiagra- 
mo) a grafikus alapobjektumokat határozzák meg, és a Rajzol megvalósításával vonalakat, 
téglalapokat és szöveget rajzolnak ki. Mivel a grafikus alapelemeknek nincsenek gyermeke- 
ik, az említett alosztályok egyike sem valósít meg gyermekekkel kapcsolatos műveleteket. 


A Kép Cicture) osztály a Grafika objektumok összetételét (aggregátumáD határozza meg. 
Ez az osztály úgy valósítja meg a Rajzol műveletet, hogy meghívja azt gyermekeire, és biz- 
tosítja hozzá a megfelelő gyermekfüggő műveleteket. A Kép felület illeszkedik a Grafika fe- 
lülethez, így a Kép objektumokból önhívással újabb Kép objektumok állíthatók elő. 


Az alábbi diagram a Grafika objektumokból önhívással felépített objektum-összetételek jel- 
legzetes szerkezetét mutatja: 







egyKép egyTéglalap 
















Alkalmazhatóság 


Az Összetétel minta használata a következő esetekben célszerű: 


e Objektumok rész-egész viszonyait szeretnénk ábrázolni. 

e Azt szeretnénk, hogy az ügyfelek figyelmen kívül hagyhassák az önálló objektumok 
és az objektum-összetételek közötti különbséget, és az összetett szerkezet minden 
objektumát egyformán kezelhessék. 
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Szerkezet 












w Ügyfél [d Elem 


Műveletf) 
Hozzáad(Elem) 
Eltávolít(Elem) 
SzerezGyermekíint) 











forall g in gyermekek sg 


Műveletl) TT TT T TT TTT g.Művelet(); 
Hozzáad(Elem) 
Eltávolít(Elem) 
SzerezGyermek(int) 





Egy jellegzetes Összetétel objektum szerkezete így festhet: 





Résztvevők 


e Elem (Grafika) 
— Bevezeti az összetétel objektumainak felületét. 
— Megfelelő alapértelmezett viselkedést valósít meg az osztályok közös felülete 
számára. 
— Felületet vezet be gyermekelemei elérésére és kezelésére. 
— (Nem kötelező) Felületet határoz meg egy elem szülőjének elérésére, és ha szük- 
séges, meg is valósítja. 
e Levél (Téglalap, Vonal, Szöveg stb.) 
— Az összetétel levélobjektumait képviseli. A levelek olyan objektumok, amelyek- 
nek nincsenek gyermekeik. 
— Meghatározza az összetétel alapobjektumainak viselkedését. 
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e Összetétel (Kép) 

— Meghatározza a gyermekekkel rendelkező elemek viselkedését. 

— Gyermekelemeket tárol. 

- Megvalósítja az Elem (Componen?t) felület gyermekekkel kapcsolatos műveleteit. 
a Ügyfél 

- Műveleteket végez az összetétel objektumaival az Elem felületen keresztül. 


Együttműködés 


e Az ügyfelek az Elem osztály felülete segítségével létesítenek kapcsolatot az összeté- 
tel objektumaival. Ha a címzett egy Levél (Leaf), a kérelem kezelése közvetlenül tör- 
ténik, ha pedig Összetétel (Composite), akkor a kérelem általában továbbítódik az 
összetétel gyermekelemeihez. A továbbítás előtt, illetve után további műveletekre is 
sor kerülhet. 


Következmények 


Az Összetétel minta előnyei és hátrányai a következők: 


1. Alap- és összetett objektumokból álló osztályhierarchiákat határoz meg. Az alapobjek- 
tumokból bonyolultabb objektumok alkothatók, amelyek maguk is összeépíthetők, és 
így tovább. Az alapobjektumot váró ügyfélkódnak összetett objektum is átadható. 

2. Egyszerűsíti az ügyfélprogramot. Az ügyfelek az önálló objektumokat és az összetett 
szerkezeteket egységesen kezelhetik. Normál esetben nem tudják (és nem is szüksé- 
ges tudniuk), hogy levél- vagy összetett objektummal van-e dolguk. Ez egyszerűbbé 
teszi az ügyfél kódját, mert így nem kell esetágakat tartalmazó függvényeket írnunk 
az összetételt felépítő minden osztályhoz. 

3. Megkönnyíti az új elemek felvételét. Az új Összetétel és Levél alosztályok automati- 
kusan működnek együtt a már meglevő szerkezetekkel és ügyfélkóddal; az ügyfele- 
ket nem kell módosítani, amikor új Elem osztályokat hozunk létre. 

4. A program túlságosan általános lehet. Az új elemek hozzáadásának megkönnyítése 
azzal a hátránnyal jár, hogy nehezebben szabályozhatjuk az összetételek elemeit 
— egyes esetekben ugyanis arra lehet szükség, hogy egy összetétel csak bizonyos 
elemeket tartalmazzon. Az Összetétel mintát használva nem támaszkodhatunk a tí- 
pusrendszerre, így az ilyen megkötéseket annak segítségével nem kényszeríthetjük 
ki, helyette futásidejű típusellenőrzést kell alkalmaznunk. 
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Megvalósítás 


Az Összetétel minta megvalósításánál a következőkre kell figyelnünk: 


1. Kifejezett szülőhivatkozások. Ha egy gyermekelemből annak szülőjére hivatkozunk, 
megkönnyítjük az összetett szerkezet bejárását és kezelését. A szülőhivatkozások 
egyszerűbbé teszik a feljebb lépést a szerkezetben, illetve az elemek törlését, emel- 
lett segítenek a Felelősséglánc minta támogatásában is. 

A szülőhivatkozás meghatározásának helye általában az Elem osztály. A Levél és 
Összetétel osztályok örökölhetik a hivatkozást, illetve az azt kezelő műveleteket, 
Szülőhivatkozások használata esetén mindenképpen fenn kell tartanunk azt az inva- 
riánst (nem változó állításb, hogy az adott összetétel minden gyermekének szülője 
az az Összetett objektum, amely gyermekként tartalmazza őket. Ennek biztosítására 
a legegyszerűbb mód, ha az elemek szülőjét kizárólag akkor változtatjuk meg, ami- 
kor egy összetételhez hozzáadjuk vagy onnan eltávolítjuk őket. Ha ennek megvaló- 
sítását az Összetétel osztály Hozzáad (Add) és Eltávolít (Remove) műveleteibe he- 
lyezzük, az alosztályok valamennyien örökölhetik, az invariáns fenntartása pedig au- 
tomatikus lesz. 

2. Az elemek megosztása. Az elemeket gyakran célszerű megosztani, például a tárigény 

csökkentése végett, de amikor egy elemnek nem lehet egynél több szülője, az ilyen 
megosztás nem könnyű. 
Egy lehetséges megoldás, ha a gyermekek több szülőt tárolnak, de ez zavart okoz- 
hat, ahogy a kérelmek feljebb haladnak a szerkezetben. A Pehelysúlyú mintánál 
majd látni fogjuk, hogyan tervezhetjük át a programot úgy, hogy egyáltalán ne le- 
gyen szükség a szülők tárolására. A megoldás abban az esetben működik, ha a gyer- 
mekek elkerülhetik, hogy állapotuk egy részének vagy egészének felfedése nélkül 
kérelmeket küldjenek a szülőknek. 

3. Az Elem felület lehető legnagyobbra bővítése. Az Összetétel minta egyik célja, hogy az 
ügyfelek ne tudjanak róla, melyik Levél vagy Összetétel osztályokat is használják. 
E cél eléréséhez az Elem osztálynak a lehető legtöbb műveletet kell meghatároznia az 
Összetétel és Levél osztályokhoz. Az osztály általában alapértelmezett megvalósítást 
is nyújt ezekhez a műveletekhez, amit a Levél és Összetétel alosztályok felülbírálnak. 
Mindazonáltal a fenti célkitűzés néha összeütközésbe kerül az osztályhierarchia-ter- 
vezés azon alapelvével, miszerint egy osztálynak csak azokat a műveleteket szabad 
meghatároznia, amelyek értelemmel bírnak alosztályai számára. Az Elem által támo- 
gatott műveletek közül azonban számosnak láthatólag nincs értelme a Levél osztá- 
lyok esetében. Hogyan adhat hát az Elem alapértelmezett megvalósítást hozzájuk? 
Némi kreativitás szükségeltetik: egy művelet, amelynek csak Összetétel osztályok 
esetében lenne értelme, minden Elemre megvalósítható, ha az Elem osztályba he- 
lyezzük. A gyermekek elérésére szolgáló felület például alapvető része az Összetétel 
osztályoknak, míg a Levél osztályoknak nem feltétlenül, de ha a Levél osztályt olyan 
Elemnek tekintjük, amelynek soha nincsenek gyermekei, az Elem osztályban máris 
meghatározhatunk egy alapértelmezett gyermekelérő műveletet, amely soha nem 
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ad vissza gyermekeket. A Levél osztályok ezt az alapértelmezett megvalósítást hasz- 

nálhatják, míg az Összetétel osztályok a műveletnek új megvalósítást adva visszaad- 

hatják gyermekeiket. 

A gyermekkezelő műveletek több gondot jelentenek, így ezeket külön pontban 

tárgyaljuk. 

4. A gyermekkezelő műveletek bevezetése. Bár az Összetétel osztály megvalósítja a gyer- 
mekek kezelésére szolgáló Hozzáad (Add) és Eltávolít (Remove) műveleteket, az 
Összetétel minta egyik fontos kérdése, hogy a hierarchia mely osztályai vezetik be 
(deklarálják) ezen műveleteket. Vezessük be őket az Elem osztályban és értelmez- 
zük a Levél osztályokra, vagy bevezetésük és meghatározásuk csak az Összetétel 
osztályban és alosztályaiban történjen? 

A döntést az befolyásolja, hogy a biztonság vagy az átlátszóság fontosabb: 

. Ha a gyermekkezelő felületet az osztályhierarchia gyökerében határozzuk meg, 
az átlátszóság mellett döntünk; ekkor minden elemet egységesen kezelhetünk. 
Ezzel azonban feláldozzuk a biztonságot, mert az ügyfeleknek lehetőséget terem- 
tünk arra, hogy értelmetlen dolgokkal próbálkozzanak, például objektumokat 
próbáljanak levelekhez adni vagy eltávolítani onnan. 

s Ha a gyermekkezelést az Összetétel osztályba helyezzük, a program biztonságo- 

sabb lesz, mert a Cs-4-hoz hasonló statikus típusokra épülő nyelvekben fordítás- 

kor elfoghatjuk az előző pontban említett értelmetlen műveletekre irányuló kísér- 
eteket. Az átlátszóságot azonban elveszítjük, hiszen a levelek és az összetételek 
elülete különböző lesz. 

A tárgyalt tervezési mintában eddig az átlátszóságot részesítettük előnyben a bizton- 

sággal szemben. Ha mégis a biztonságra voksolnánk, előfordulhat, hogy típusinfor- 

mációt vesztünk, és egy elemet összetétellé kell alakítanunk. Hogyan tehetjük ezt 
meg anélkül, hogy nem biztonságos típuskényszerítéshez (cast) folyamodnánk? 

Az egyik megoldás egy Összetételt Szerezöősszetétel ( ) (Compositer Get- 

Composite ( ) ) művelet bevezetése az Elem osztályban. Az Elem biztosít egy alapér- 

telmezett műveletet, amely egy nullmutatót ad vissza. Az Összetétel osztály e művelet 

felülírásával saját magát adja vissza a this mutatón keresztül: 
class Composite; 








class Component ( 
public: 

Efsvs 

virtual Compositer GetComposite() ( return 0; ) 
b; 


class Composite : public Component ( 
public: 
void Add(Component" ) ; 
Pss 
virtual Compositer GetComposite() ( return this ) 
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class Leaf : public Component ( 
ffszs 

hb 
A GetComposite (SzerezÖsszetétel) lehetővé teszi, hogy megkérdezzük az elemet, 
hogy összetett objektum-e. A visszaadott összetételen biztonságosan végrehajthatók 
az Add és Remove műveletek. 

Compöósitet aComposite - new Composite; 

Leafr aLeaf - new Leaf; 


Componentt aComponent; 
Compositet test; 


aComponent - aComposite; 
if (test - aComponent-:GetComposite()) ( 
teést-sAdd(new Leaf) ; 


aComponent - aLeaf; 


if (test - aComponent-5GetComposite()) ( 
test-sAdd(new Leaf);// nem ad hozzá levelet 

) 
Egy összetételre hasonló ellenőrzést a Ct- dynamic cast szerkezetével végezhetünk. 
A gond itt természetesen az, hogy az egyes elemeket nem egységesen kezeljük, így 
ellenőriznünk kell a típust, mielőtt végrehajthatnánk a megfelelő műveletet. 
Az átlátszóság biztosítására az egyetlen út, ha az Elemben alapértelmezett Add és 
Remove műveleteket határozunk meg, ami viszont újabb gonddal jár: 
a Component : : Add nem valósítható meg anélkül, hogy fenn ne álljon annak a le- 
hetősége, hogy a művelet nem jár sikerrel. Megtehetjük, hogy a műveletnek azt 
mondjuk, ne csináljon semmit, de ekkor figyelmen kívül hagyjuk azt a tényt, hogy 
a levélhez való hozzáadás kísérlete valószínűleg hibát jelez, mely esetben az Add 
művelet szemetet , állít elő". Esetleg arra utasíthatjuk, hogy törölje argumentumát, de 
az ügyfelek valószínűleg nem számítanak erre. 
Ha az adott elemnek nem lehet gyermeke, vagy ha a Remove argumentuma nem az 
elem gyermeke, általában jobb, ha az Add és a Remove alapértelmezés szerint nem 
járnak sikerrel (például kivételt váltanak ki). 
Egy másik lehetőség, hogy némileg módosítjuk az , eltávolítás" (remove) jelentését. 
Ha az elem hivatkozik a szülőjére, a Component : : Remove műveletet felülírhatjuk 
úgy, hogy az elem eltávolítsa magát a szülőjéből, de a megfelelő Add műveletet ek- 
kor sem tehetjük értelmessé. 
Tartalmazza-e az Elem az elemek listáját? Csábíthat a lehetőség, hogy az Elem osz- 
tályban, ahol a gyermekelérő és -kezelő műveleteket bevezetjük, példányváltozó- 
ként meghatározzuk a gyermekek halmazát. A gyermekmutatónak az alaposztályba 
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helyezése azonban külön tárigényt jelent minden levél esetében, még akkor is, ha 
a leveleknek soha nincsenek gyermekeik. A megoldás csak akkor kifizetődő, ha 
a szerkezetben viszonylag kevés gyermek található. 

A gyermekek sorrendje. Az összetételek gyermekeinek sorrendjét gyakran meghatá- 
rozzák. A korábbi Grafika példában a sorrend az előtér—háttér sorrendet tükrözheti. 
Ha az összetételek elemzőfákat képviselnek, az összeállító utasítások egy olyan 
Összetétel példányai lehetnek, amelynek gyermekeit sorrendbe kell állítani, hogy 
tükrözzék a program felépítését. 

Ha a gyermekek sorrendje fontos, a gyermekelérő és -kezelő felületeket gondosan 
kell megterveznünk, hogy megfelelően kezelhessük a gyermekek sorozatát. Ebben 
a Bejáró tervezési minta segíthet. 

Átmeneti tár (cache) használata a teljesítmény javítására. Ha gyakran kell bejárást 
vagy keresést végeznünk az összetételekben, a gyermekekkel kapcsolatos bejárási 
és keresési információkat az Összetétel osztály átmenetileg tárolhatja. A tárban elhe- 
lyezhetjük az aktuális eredményeket, de szorítkozhatunk azokra az információkra is, 
amelyek a bejárás vagy keresés lerövidítését szolgálják. A Feladat részben bemuta- 
tott Kép (Picture) osztály például tárolhatja gyermekei befoglaló dobozát, így rajzo- 
lás vagy kijelölés közben elkerülheti, hogy műveleteket végezzen azokon a gyerme- 
keken, amelyek éppen nem láthatók az ablakban. 

Ha egy elem megváltozik, szülőinek átmeneti tárát érvényteleníteni kell. Ez akkor 
a legkönnyebb, amikor az elemek ismerik szülőiket. Tehát ha átmeneti tárolást alkal- 
mazunk, meg kell határoznunk egy felületet, amelynek segítségével tájékoztathatjuk 
az összetételeket, hogy táruk érvénytelen. 

Ki törölje az elemeket? A szemétgyűjtés nélküli nyelvekben általában az a legjobb, ha 
az Összetételek felelnek gyermekeik törléséért, amikor az összetétel megsemmisül. 
E szabály alól kivételt jelent, amikor a levélobjektumok nem módosulók (immu- 
table), és így megoszthatók. 

Melyik a legjobb adatszerkezet az elemek tárolására? Az összetételek különféle 
adatszerkezeteket használhatnak gyermekeik tárolására: láncolt listákat, fákat, töm- 
böket és kivonattáblákat (hasítótábla, hash). A választott adatszerkezet (mint min- 
dig) attól kell, hogy függjön, melyik a hatékonyabb. Valójában még az sem szüksé- 
ges, hogy általános célú adatszerkezetet használjunk. Az összetételek időnként kü- 
lön változókat tartanak fenn az egyes gyermekek számára, pedig ez azt igényli, hogy 
az Összetétel minden alosztálya saját kezelőfelületet valósítson meg. Példát az Értel- 
mező mintánál láthatunk, a következő fejezetben. 


Példakód 


Az olyan részegységekből álló eszközöket, mint a számítógép vagy egy hi-fi berendezés, 
gyakran rész-egész vagy , tartalmazza" viszonyok alapján ábrázoljuk. A számítógépház pél- 
dául a meghajtókat és az alaplapot tartalmazza, a busz a kártyákat, és így tovább. Az ilyen 
felépítés természetes módon modellezhető az Összetétel minta segítségével. 
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Az Eguipment (Eszközök) osztály határozza meg a rész-egész hierarchia összes részegy- 
ségére érvényes felületet: 


class Eguipment ( 
public: 


virtual "Eguipment ( ) ; 
cöonst char Name() ( return name; ) 


virtual Watt Power ( ) ; 
virtual Currency NetPrice(); 
virtual Currency DiscountPrice( ) ; 


virtual void Add(Eguipment" ) ; 

virtual void Remove(Eguipment? ) ; 

virtual IteratorcEguipmentt5r Createlterator(); 
protected: 

Eguipment (const char"); 
private: 

const chart name; 
L; 


Az Eguipment olyan műveleteket vezet be, amelyek a részegységek tulajdonságait adják 
vissza, például fogyasztásukat és árukat. Az alosztályok ezeket a műveleteket adott rész- 
egység-típusokra valósítják meg. Az Eguipment emellett bevezeti a Createlterator 
(LétrehozBejáró) műveletet is, amely egy, az elemek elérésére szolgáló bejárót (Iterator, 
lásd a C függeléke) ad vissza. E művelet alapértelmezett megvalósítása egy Nulllterator-t 
ad vissza, amely az üres halmaz bejárására szolgál. 


Az Eguipment alosztályai olyan levélosztályokat tartalmazhatnak, amelyek a lemezmeg- 
hajtókat, integrált áramköröket és kapcsolókat jelképezik: 


class FloppyDisk : public Eguipment ( 
püblic: 
FloppyDisk(const char"); 


virtual "FloppyDisk() ; 


virtual Watt Power (); 

virtual Currency NetPrice(); 

virtual Currency DiscountPrice() ; 
1; 


A más részegységeket tartalmazó részegységek alaposztálya a CompositeEguipment 
CÖsszetettEszközök), amely egyben az Eguipment alosztálya: 
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class CompositeEguipment : public Eguipment ( 
public: 


virtual "CompositeEguipment ( ) ; 


virtual Watt Power () ; 
virtual Currency NetPrice(); 
virtual Currency DiscountPrice( ); 


virtual void Add(Eguipmentt ) ; 
virtual void Remove (Eguipment" ) ; 
virtual ItératorcEguipmenttst Createlteratot ( ) ; 


protected: 

CompositeEguipment (const char"); 
private: 

ListcEguipmentts5 . eguipment ; 
); 


A CompositeEguipment az alegységek elérésére és kezelésére szolgáló műveleteket hatá- 
rozza meg. Az Add (Hozzáad) művelet alegységeket szúr be az alegységek . eguipment tag- 
ban tárolt listájába, míg a Remove (Eltávolít) törli azokat onnan. A CreateIterator művelet 
egy bejárót ad vissza (mégpedig egy ListIterator-példányt), amely majd bejárja a listát. 


A NetPrice (NettóÁr) alapértelmezett megvalósítása a Createlterator segítségével 
összegzi az alegységek nettó árát: 


Currency CompositeEguipment: :NetPrice () ( 
IteratorcEguipmenttortr i - Createlterator (); 
Currency total - 0; 


for (i-sFirst(); !i-sIsDone(); i-sNext()) ( 
total 4- i-sCurrentItem()-sNetPrice() ; 

1; 

delete i; 

return total; 


Most már ábrázolhatunk egy számítógép-házat, a CompositeEguipment osztály Chassis 
(Ház) nevű alosztályaként. A Chassis a gyermekekkel kapcsolatos műveleteket örökli 
a CompositeEguipment-től. 


class Chassis : public CompositeEguipment ( 
public: 
Chassis(const char") 





? A bejáró törléséről könnyű megfeledkezni, amikor már végeztünk a használatával. A Bejáró mintánál megmutat- 
juk, hogyan védekezhetünk az ilyen hibák ellen. 
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virtual "7Chassis(); 


virtual Watt Power —(); 
virtual Currency NetPrice(); 
virtual Currency DiscountPrice(); 


); 


A hasonló tárolókat ugyanígy határozhatjuk meg, és máris felépíthetjük (elég egyszerű) 
személyi számítógépünket: 


Cabinetr cabinet - new Cabinet("PC Cabinet"); 
Chassist chassis - new Chassis("PC Chassis"); 


cabinet-s5Add(chassis) ; 


Bus" bus - new Bus("MCA Bus"); 
bus-sAdd(new Card("16Mbs Token Ring")); 


chassis-sAdd(bus) ; 
chassis-sAdd(new FloppyDisk("3.5in Floppy" )); 


cout cx "A nettó ár: " cc chassis-sNetPrice() cc endi; 


Ismert felhasználások 


Az Összetétel minta alkalmazására szinte minden objektumközpontú rendszerben találha- 
tunk példát. A Smalltalk Model/View/Controller IKP88] eredeti View osztálya is összetétel 
volt, és szinte valamennyi felhasználói felületi elemkészlet és keretrendszer követte a pél- 
dáját, köztük az ET-4-4 a VObjects-szel IWGM88], az InterViews a Styles-szal ILCI--92], 
a Graphics ÍVL88] és a Glyphs ICL90]. Az érdekesség kedvéért megemlítendő, hogy az ere- 
deti View-hoz alnézetek halmaza tartozott, vagyis a View egyszerre töltötte be az Elem és 
az Összetétel osztály szerepét. A Smalltalk-80 4.0-ás kiadásában a Model/View/Controller 
rendszert átdolgozták; itt már egy VisualComponent (VizuálisElem) nevű osztályt találunk, 
View és CompositeView (ÖsszetettNézet) alosztályokkal. 


Az RTL Smalltalk-fordítói keretrendszer [JML92] kiterjedten használja az Összetétel mintát. 
Az RTLExpression (RTLKifejezés) elemzőfák Component (Elem) osztálya, amelynek alosz- 
tályai, például a BinaryExpression (BinárisKifejezés), gyermek RTLExpression objektumo- 
kat tartalmaznak. Ezek az osztályok építik fel az elemzőfák összetett szerkezetét. A progra- 
mok köztes Single Static Assignment (SSA) formájának Elem osztálya a RegisterTransfer, 
melynek levél-alosztályai különböző statikus hozzárendeléseket határoznak meg: 


s alapvető hozzárendeléseket, melyek során két regiszteren hajtanak végre egy műve- 
letet, majd az eredményt egy harmadikhoz rendelik; 

e a forrásregiszteren kívül célregiszterrel nem rendelkező hozzárendelést, ami azt jelzi, 
hogy a regisztert egy függvény visszatérése után használjuk; 
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s forrással nem, csak célregiszterrel rendelkező hozzárendelést, ami azt jelzi, hogy 
a regiszter használatára a függvény elindulása előtt kerül sor. 


A RegisterTransferSet alosztály az egyszerre több regisztert módosító hozzárendelések 
Összetétel osztálya. 


A minta pénzügyi területen való alkalmazására példa, amikor egy portfolió pénzügyi esz- 
közöket összesít. Ha a portfoliót olyan összetételként valósítjuk meg, amely megfelel az 
egyes eszközök felületének, bonyolult összesítéseket végezhetünk [BE93]. 


A Parancs minta leírja, hogyan építhetők össze és állíthatók sorba a Parancs objektumok 
egy MakróParancs (MacroCommand) Összetétel osztály segítségével. 


Kapcsolódó minták 

Az elem-szülő hivatkozásokat gyakran alkalmazzák felelősségláncok építésére. 

A Díszítő minta gyakran használatos együtt az Összetétel mintával. Ilyenkor a díszítők és 
összetételek szülőosztálya általában közös, ezért a díszítőknek olyan műveletekkel kell tá- 
mogatniuk az Elem felületet, mint a Hozzáad (Add), az Eltávolít (Remove) vagy a Szerez- 


Gyermek (GetChild). 


A Pehelysúlyú minta révén megoszthatjuk az elemeket, de ekkor azok nem hivatkozhatnak 
többé szülőjükre. 


Az összetételek bejárására a Bejáró minta alkalmazható. 


A Látogatók olyan viselkedést és műveleteket gyűjthetnek egy helyre, amelyek másképp 
megoszlanának az Összetétel és Levél osztályok között. 
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FAT PU 4 
Díszítő 
Szerkezeti objektumminta 
cél 


Az objektumokhoz dinamikusan további felelősségi köröket rendelni. A kiegészítő szolgál- 
tatások biztosítása terén e módszer rugalmas alternatívája az alosztályok létrehozásának. 


Egyéb nevek 


Decorator, Wrapper (Burkoló) 


Feladat 


Időnként egyes objektumokhoz, nem pedig egy teljes osztályhoz szeretnénk felelősségeket 
rendelni. Egy grafikus felhasználói felületi elemkészlet például lehetővé kell tegye olyan tu- 
lajdonságok, illetve viselkedések felvételét bármely felületelemhez, mint amilyenek a sze- 
gélyek vagy a görgetés. 


A felelősségek hozzáadására az egyik mód az öröklés. Ha egy szegélyt például egy adott 
osztálytól öröklünk, annak valamennyi alosztály-példánya körül megjelenik a szegély. 
Ez a megoldás azonban rugalmatlan, mert azt, hogy van-e szegély, statikusan döntjük el, az 
ügyfelek nem szólhatnak bele, mikor és hogyan díszítjük az elemet szegéllyel. 


Ennél rugalmasabb megoldás, ha az elemet egy másik objektumba ágyazzuk, amely gon- 
doskodik a szegély hozzáadásáról. A beágyazó objektumot nevezzük díszítőnek. A díszítő 
a díszített elem felületéhez igazodik, így jelenléte észrevétlen marad az elem ügyfelei szá- 
mára. A díszítő továbbítja a kérelmeket az elemhez, és a továbbítás előtt vagy után egyéb 
műveleteket is végrehajthat (például szegélyt rajzolhaD. Az átlátszóság révén több díszítő is 
egymásba ágyazható, így korlátlan számú tulajdonsággal vagy tevékenységgel egészíthet- 
jük ki a rendszert. 


egySzegélyDíszítő 
egyGörgetésDíszítő 


egySzövegNézet 
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Példaként tegyük fel, hogy van egy SzövegNézet (TextView) objektumunk, amely szöveget 
jelenít meg egy ablakban. A SzövegNézet alapállapotban nem rendelkezik gördítősávval, 
hiszen arra nem mindig van szükség. Amikor kell, hozzáadásáról egy GörgetésDíszítő 
(ScrollDecorator) objektummal gondoskodunk. Tegyük fel, hogy emellett vastag fekete 
szegélyt is szeretnénk rajzolni a SzövegNézet köré — ezt egy SzegélyDíszítő (BorderDeco- 
rator) végezheti. A díszítőket egyszerűen összeépítjük a SzövegNézet objektummal, és már- 
is elérjük a kívánt eredményt. 


Az alábbi objektumdiagram azt mutatja, hogyan építhető össze a SzövegNézet objektum 
a SzegélyDíszítő, illetve GörgetésDíszítő objektumokkal, hogy egy szegéllyel ellátott, gör- 
gethető szövegnézőkét hozhassunk létre: 






egySzegélyDíszítő 


elem 0— 






egyGörgetésDíszítő 





egySzövegNézet 








A GörgetésDíszítő és a SzegélyDíszítő a Díszítő (Decorator) alosztályai, amely a más látható 
elemeket díszítő látható elemek elvont osztálya. 









LáthatóElem 


Rajzolt) 














SzövegNézet 


Rajzol() avail Ózd egnlztzttttnattátzosátatétt 











elem-—3 Rajzol() 





























GörgetésDíszítő SzegélyDíszítő 

2 TZOŰ, . özszzennereasztszkéséő Díszítő::Rajzol(); 9 
Rajzol() jugó RajzolSzegélyí); 
Görgetide[) RajzolSzegélyt) 














görgetésPozíció szegélySzélesség 
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A LáthatóElem (VisualComponen?) a látható elemek elvont osztálya; azok rajzoló és ese- 
ménykezelő felületét határozza meg. Megfigyelhetjük, hogy a Díszítő (Decorator) osztály 
egyszerűen továbbítja a rajzolási kérelmeket a hozzá tartozó elemhez, alosztályai pedig ki- 
bővítik ezt a műveletet. 


A Díszítő alosztályok szabadon biztosíthatnak további műveleteket. A GörgetésDíszítő 
(ScrollDecorator) Görgetéslde (ScrollTo) művelete például lehetővé teszi más objektumok 
számára, hogy görgessék a felületet, a tudják, hogy a felület GörgetésDíszítő objektumot 
tartalmaz. A tervezési minta lényeges vonása, hogy díszítők bárhol alkalmazhatók, ahol egy 
LáthatóElem megjelenhet. Emiatt az ügyfelek általában nem tudnak különbséget tenni egy 


díszített és egy díszítetlen elem között, így telj 


Alkalmazhatóság 


A Díszítő minta az alábbi esetekben alkalmaz! 


e Egyes objektumokat dinamikusan és át 


esen függetlenek maradhatnak a díszítéstől. 


lató: 


láts 





óan, vagyis más objektumokat nem érint- 


ve bizonyos felelősségi körökkel szeretnénk kiegészíteni. 


s Eltávolítható jellemzőket szeretnénk fel 


venni. 





e Az alosztályokkal való bővítés nem cél 





szerű. Előfordulhat, hogy nagy számú önálló 


bővítés lehetséges, de az egyes kombinációk támogatása az alosztályok számának 
erű növekedéséhez vezetne. Az is lehetséges, hogy a kívánt osztály-meg- 
s rejtett vagy más módon hozzáférhetetlen alosztály-létrehozás céljára. 































































































Szerkezet 
Elem 
Műveletí) 
I elem 
KonkrétElem Díszítő 
Művelet() Műveletí) 0------- eses eses esése ed elem— Művelet() 
KonkrétDíszítőA Í  KonkrétDíszítőB ss 
Díszítő::Művelet(); 
Művelet() MSAT eza j ttszá ae Hozzáadottviselkedésí); 
HozzáadottViselkedést) 
hozzáadottÁllapot 
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Résztvevők 


Elem (LáthatóElem) 

— Meghatározza azon objektumok felületét, amelyek különféle felelősségekkel di- 
namikusan bővíthetők. 

KonkrétElem (SzövegNéze) 

— Egy objektumot határoz meg, amelyhez kiegészítő felelősségek csatolhatók. 

Díszítő 

- Egy Elem (ComponenD) objektumra hivatkozik, és olyan felületet határoz meg, 
amely megfelel az Elem felületének. 

KonkrétDíszítő (SzegélyDíszítő, GörgetésDíszítő) 

— Felelősségeket rendel az elemhez. 


Együttműködés 


A Díszítő (Decorator) kérelmeket továbbít Elem (Component) objektumához, ezen 
kívül a kérelem továbbítása előtt vagy után egyéb műveleteket is végrehajthat. 


Következmények 


A Díszítő mintának legalább két lényeges előnye és két hátránya van: 


ds 


A statikus öröklésnél rugalmasabb. A Díszítő minta rugalmasabb módot nyújt az ob- 
jektumok felelősségi körökkel való bővítésére, mint a statikus (többszörös) öröklés; 
az új képességek hozzáadása és eltávolítása futásidőben egyszerűen, pusztán a díszí- 
tők csatolásával és leválasztásával lehetséges. Ezzel szemben az öröklés új osztályok 
(pl. SzegélyesGörgethetőSzövegNézet, SzegélyesSzövegNézet) létrehozását igényli 
minden új képességhez, ami rengeteg osztályhoz, s így bonyolultabb rendszerhez 
vezet. Ezen kívül, ha egy adott Elem osztályhoz különböző Díszítő osztályokat bizto- 
sítunk, a felelősségi köröket egymáshoz illeszthetjük és keverhetjük is. 

A díszítők azt is egyszerűbbé teszik, hogy egy tulajdonságot kétszer vegyünk fel. 
Ha egy SzövegNézethez például kettős szegélyt szeretnénk adni, csak két Szegély- 
Díszítőt (BorderDecorator) kell hozzácsatolnunk. A Szegély (Border) osztályból való 
kétszeres öröklés ezzel szemben legalábbis könnyebben hibát eredményezhet. 
Elkerülhető a képességeket tartalmazó osztályok túl magasra helyezése a hierarchiá- 
ban. A Díszítő minta használatakor a felelősségek hozzáadásának költségeit fokozato- 
san fizetjük meg. Nem kell azzal próbálkoznunk, hogy egy bonyolult, testreszabható 
osztályban támogassunk minden elképzelhető képességet; helyette elég egy egyszerű 
osztályt meghatároznunk, és díszítő objektumokkal fokozatosan hozzáadni a kívánt 
szolgáltatásokat. A szolgáltatások így egyszerű elemekből építhetők fel, az alkalmazás- 
nak pedig nem kell fizetnie olyan képességekért, amelyeket nem használ. Emellett 
egyszerű a bővítendő objektumok osztályaitól függetlenül új fajta díszítőket meghatá- 
rozni, még előre nem látható bővítések esetében is. Ezzel szemben egy bonyolult osz- 
tály bővítése a hozzáadott képességekkel kapcsolatban nem álló részleteket fedne fel. 
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3. A díszítő és a hozzá tartozó elem nem azonos. A díszítők átlátszó egységként viselked- 
nek, de az objektumok azonossága szempontjából egy díszített objektum nem azonos 
az eredeti objektummal, így nem is építhetünk erre, amikor díszítőket alkalmazunk. 

4. Számos kisméretű objektum jön létre. A Díszítő minta használata gyakran olyan 
rendszert eredményez, amely számos hasonló kinézetű apró objektumból áll. Ezen 
objektumok csak kapcsolódásuk módjában különböznek, osztályukat és a változó- 
ikban tárolt értékeket tekintve nem. Bár egy ilyen rendszer a szakértő számára 
könnyen testreszabható, nehéz átlátni, és a hibakeresést is megnehezíti. 


Megvalósítás 


A Díszítő minta megvalósítása során az alábbiakra kell tekintettel lennünk: 


1. A felület megfelelősége. A díszítő objektum felületének illeszkednie kell az általa dí- 
szített elem felületéhez. A KonkrétDíszítő (ConcreteDecorator) osztályoknak ezért 
egy közös osztályból kell öröklődniük (legalábbis a C-----ban). 

2. Az elvont Díszítő osztály kihagyása. Ha csak egy képességet szeretnénk felvenni, 
nincs szükség elvont Díszítő osztály meghatározására. Ha nem új osztályhierarchiát 
építünk, hanem egy meglevővel dolgozunk, gyakran ez a helyzet. Ebben az esetben 
a Díszítő azon szolgáltatását, hogy kérelmeket továbbít az elemhez, a KonkrétDíszítő 
osztályba helyezhetjük. 

3. Az Elem osztályok pehelysúlyűvá tétele. A felület megfelelőségének biztosítása érde- 
kében az elemeket és díszítőiket egy közös Elem osztályból kell származtatni. Fontos, 
hogy ez a közös osztály pehelysúlyú legyen, vagyis a felület meghatározására, nem 
pedig adatok tárolására összpontosítson, Az adatábrázolás meghatározását az alosz- 
tályokra kell hagyni, másképp az Elem osztály bonyolultsága túl , nehézzé" teszi a dí- 
szítőket ahhoz, hogy sokat lehessen használni belőlük. Emellett az Elem osztály szá- 
mos szolgáltatással való terhelése annak valószínűségét is növeli, hogy a konkrét al- 
osztályok olyan szolgáltatásokért fizetnek, amelyekre nincs is szükségük. 

4. Az objektumok , bőrének" megváltoztatása a ,, belsőségek" helyett. A díszítőkre úgy 
gondolhatunk, mint egy viselkedését változtató objektum bőrére. Ezzel szemben 
a Stratégia mintában például az objektum belső részeit módosítjuk. 

A stratégiák alkalmazása az olyan helyzetekben jobb választás, amikor az Elem osztály 
eredendően nehézsúlyú, így a Díszítő minta használata túl költséges lenne. A Stratégia 
mintában az elemek viselkedésük egy részét külön stratégia objektumokba helyezik; 
ezek cseréjével változtathatók vagy bővíthetők az adott elem szolgáltatásai. 
Különböző szegélystílusokat például úgy támogathatunk, ha az elem szegélyrajzoló 
képességét egy önálló Szegély (Border) objektumra ruházzuk át. A Szegély egy olyan 
Stratégia objektum, amely egy szegélyrajzoló stratégiát zár egységbe. A stratégiák szá- 
mának bővítésével ugyanaz a hatás érhető el, mint a díszítők egymásba ágyazásával. 
A MacApp 3.0-ban (lApp89] és a Bedrock-ban [Sym93a] például grafikus objektumok 
Cúgynevezett , nézetek") ,dísz" (adorner) objektumok listáját tartják fenn, amelyek 
a szegélyekhez hasonló díszítéseket csatolhatnak egy nézet objektumhoz. Ha egy né- 
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zethez díszek csatlakoznak, a nézet megengedi nekik, hogy feldíszítsék. A MacApp és 
a Bedrock azért szorul erre a megoldásra, mert a View (Néze0) osztály nehézsúlyú, így 
túl költséges lenne egy teljes értékű View használata pusztán egy szegély hozzáadására. 
Mivel a Díszítő minta csak kívülről változtat meg egy elemet, az elemnek semmit 
sem kell tudnia díszítőiről, vagyis azok átlátszóak számára: 


egyDíszítő 


elem e- 








bővítés díszítővel szzzszal 


Stratégiák használata esetén az elem ismeri a lehetséges bővítéseket, így hivatkoznia 
kell a megfelelő stratégiákra: 

















egyőretéga 
következő 


LARRNÁNBSA bővítés stratégiával szzsze ill 


A stratégia alapú megközelítés az elem módosítását igényelheti, hogy az új bővíté- 
sekre lehetőséget biztosítsunk. Másfelől, egy stratégiának egyedi felülete lehet, míg 
egy díszítőnek illeszkednie kell az elem felületéhez. Egy szegélyrajzoló stratégiának 
például csak a szegélyt megjelenítő felületet (RajzolSzegély, SzerezSzélesség — 
DrawBorder, GetWidth stb.) kell meghatároznia, ami azt jelenti, hogy a stratégia ak- 
kor is pehelysúlyú lehet, ha maga az Elem osztály nehézsúlyú. 

A MacApp és a Bedrock nem csak nézetek díszítésére használják ezt a megoldást, 
hanem az objektumok eseménykezelő viselkedésének bővítésére is. A nézetek 
mindkét rendszerben egy listát tartanak fenn a , viselkedésobjektumokról", amelyek 
képesek eseményeket elfogni és módosítani. A nézet a be nem jegyzett viselkedések 
előtt minden bejegyzett viselkedésobjektumának lehetőséget ad az esemény kezelé- 
sére, ezzel gyakorlatilag felülírja azokat. Például egy nézet úgy egészíthető ki billen- 
tyűkezeléssel, hogy bejegyzünk egy viselkedésobjektumot, amely elfogja és kezeli 
a billentyűzet felől érkező eseményeket. 
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Példakód 


A következő kód azt mutatja, hogyan valósíthatók meg a felhasználói felületi díszítők 


a Cs4-ban. Feltesszük, hogy egy VisualComponent (LáthatóElem) nevű Elem osztállyal 
rendelkezünk. 


class VisualComponent ( 
public: 
VisualComponent ( ) ; 


virtual void Draw(); 
virtual void Resize(); 
Érzés 

); 


Meghatározzuk a VisualComponent Decorator (Díszítő) nevű alosztályát, amelyből 
a különböző díszítések alosztályait fogjuk származtatni. 


class Decorator : public VisualComponent ( 
public: 
Decorator(VisualComponent" ) ; 


virtual void Draw() ; 

virtual void Resize(); 

ékek 
private: 

VisualComponentt . component; 
) ; 


A Decorator a konstruktorban előkészített component példányváltozó által hivatkozott 
VisualComponent-et díszíti. A Decorator a VisualComponent felületében szereplő 
minden művelethez alapértelmezett megvalósítást ad, amelyek a kérelmet a . component- 
hez továbbítják: 


void Decorator::Draw () ( 
.component-sDraw ( ) ; 


void Decorator::Resize () ( 
.component-—sResize(); 





A különböző díszítéseket a Decorator alosztályai határozzák meg; a BorderDecorator 
(SzegélyDíszítő) osztály például szegélyt ad befoglaló eleméhez, a Draw (Rajzol) művelet 
felülírásával. A BorderDecorator emellett egy DrawBorder (RajzolSzegély) nevű privát 
segédműveletet is meghatároz, amely a tényleges rajzolást végzi. Az alosztály minden más 
művelet megvalósítását a Decorator-tól örökli. 
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class BorderDecorator : public Decorator ( 
public: 
BorderDecorator (VisualComponent:, int borderWidth) ; 


virtual void Draw(); 
private: 

void DrawBorder (int) ; 
private: 

int . width; 
B 


void BorderDecorator::Draw () ( 
Decorator : : Draw ( ) ; 
DrawBorder( width) ; 


) 


A látható elemhez görgetési képességet és árnyékolást adó ScrollDecorator (Görgetés- 
Díszítő), illetve DropShadowDecorator (ÁrnyékvetőDíszítő) megvalósítása hasonló. 


Az említett osztályokból példányokat készítünk, amelyek biztosítják a különféle díszítése- 
ket. Az alábbi kód bemutatja, hogy a díszítők használatával hogyan hozhatunk létre egy 
szegéllyel ellátott, görgethető szövegnézetet (TextView). 


Először módot kell adnunk a látható elemek ablak objektumokba helyezésére. Feltesszük, 
hogy Window (Ablak) osztályunk erre a célra egy Setcontents (BeállítTartalom) nevű 
műveletet biztosít: 


void Window: : SetContents (VisualComponentY contents) ( 
Mfssz 
b; 


Most már létrehozhatjuk a szövegnézőt, és egy ablakot, amelyben elhelyezzük: 


Windowt window - new Window; 
TextViewt textView - new TextView; 


A TextView olyan VisualComponent, amely az ablakba helyezhető: 


window-sSetContents (textView) ; 


Csakhogy mi szegéllyel ellátott és görgethető TextView-t szeretnénk, ezért az ablakba he- 
lyezés előtt megfelelően díszítjük: 


window-5SetContents ( 
new BorderDecorator( 
new ScrollDecorator(textView), 1 
) 
); 





Díszítő 
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Mivel a Window tartalmát a VisualComponent felületen keresztül éri el, nem érzékeli 
a díszítő jelenlétét. Az ügyfél azonban nyomon követheti a szövegnéző állapotát, ha köz- 
vetlenül kell hozzáférnie, például ha olyan műveleteket kell meghívnia, amelyek nem ré- 
szei a VisualComponent felületnek. Az elem azonosságára alapozó ügyfeleknek szintén 


közvetlenül kell hivatkozniuk az elemre. 


Ismert felhasználások 


A vezérlők grafikus díszítésére számos objektumközpontú felhasználói felületi elemkész- 
let használ díszítőket. Ilyen például az InterViews ILVC89, LCI--92], az ET--- (WGM88] vagy 
az ObjectWorkstSmalltalk osztálykönyvtár [Par90]. A minta különlegesebb alkalmazására 
példa a DebuggingGlyph az InterViews-ból, illetve a PassivityWrapper a ParcPlace 
Smalltalk-ból. A DebuggingGlyph hibakeresési információt ír ki, mielőtt, illetve miután to- 
vábbít egy elrendezési kérést a hozzá tartozó elemhez. Ez a nyomkövetési információ az 
összetételek objektumai elrendezési viselkedésének elemzésére és hibakeresésére hasz- 
nálható. A PassivityWrapper az elemmel végezhető felhasználói műveletek engedélyezé- 
sére, illetve letiltására szolgál. 


A Díszítő minta azonban nem korlátozódik a grafikus felhasználói felületekre, amint azt 
a következő (az ET--4 folyamosztályain IWGM88] alapuló) példa is illusztrálja. 


Az adatfolyamok (stream) alapvető jelentőségű fogalmai a bemeneti-kimeneti (1/0) rend- 
szereknek. A folyam objektumok bájt- vagy karaktersorozattá való alakítására biztosít felü- 
letet, így egy objektumot későbbi felhasználás céljából fájllá vagy memóriában tárolt karak- 
terlánccá alakíthatunk. Ennek legegyszerűbb módja egy elvont Stream (Folyam) osztály 
meghatározása, amely egy MemoryStream és egy FileStream alosztállyal rendelkezik. De te- 
gyük fel, hogy az alábbiakra is lehetőséget szeretnénk adni: 





e az adatfolyam tömörítésére különböző tömörítő algoritmusok segítségével (futás- 
hosszú kódolás, Lempel-Ziv stb.); 

e a folyamban tárolt adatok 7 bites ASCII karakterekké csökkentésére, hogy átvihetők 
legyenek egy ASCII kommunikációs csatornán. 


A Díszítő mintával ezek a feladatok könnyen az adatfolyamokhoz adhatók. A következő 
oldalon látható diagram egy példát mutat a probléma megoldására. 


Az elvont Stream osztály egy belső átmeneti tárat (buffer) tart fenn, és műveleteket biztosít 
az adatok folyamba helyezésére (Putlnt, PutString). Amikor a tár megtelik, a Stream meghív- 
ja az elvont HandleBufferFull műveletet, amely a tényleges adatátvitelt végzi. A műveletet fe- 
lülíró FileStream-változat a tár tartalmát egy fájlba írja. 
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Stream 








Putlint0) 
PutString() 
HandleBufferFull() 


vesza gaz NT 


MemoryStream FileStream StreamDecorator s— ee 


HandleButferFulk() 9-ff-----se ee component-szHandleBufferFull() ja 


ASCWI7Stream ] CompressingStream 


adatok tömörítése az átmeneti tárban ül 
HandleButferFult() ] HandieButfferFull() 0--f----  SireamDecorator::HandleBufferFull) 


A legfontosabb osztály itt a StreamDecorator (FolyamDíszítő), amely egy elemfolyamra hi- 
vatkozik, és ahhoz kérelmeket továbbít. A StireamDecorator alosztályai felülírják a Handle- 
BufferFull műveletet, és további tevékenységeket végeznek, mielőtt meghívnák a Stream- 
Decorator HandleBufferFull műveletét. A CompressingStream (TömörítőFolyam) alosztály 
például tömöríti az adatokat, míg az ASCII7Stream 7 bites ASCII-vé alakítja azokat. Ahhoz, 
hogy olyan FileStream-et hozzunk létre, amely tömöríti adatait és a tömörített bináris adato- 
kat 7 bites ASCII-vé alakítja, a FileStream-et egy CompressingStream-mel és egy 
ASCII7Stream-mel díszítjük: 























HandleBufferFult() HandleBufferFull) 
























































StreamtY aStream - new CompressingStream( 
new ASCII7Stream( 
new FileStream( "egyFájlNév") 
) 
) a 
aStream-sPutInt (12) ; 
aStream-sPutString( "egyKarakterlánc" ) ; 


Kapcsolódó minták 


Illesztő: A díszítők annyiban különböznek az illesztőktől, hogy csak az objektumok felada- 
tát, nem pedig azok felületét változtatják meg. Az illesztők teljesen új felülettel látják el az 
objektumokat. 


Összetétel: A díszítők csökevényes összetételeknek tekinthetők, amelyeknek csak egy ele- 
mük van. Mindazonáltal a díszítők felelősségi körök hozzáadására valók, nem objektum- 
összetételre. 


Stratégia: A díszítők segítségével az objektumok , bőre" változtatható meg, míg a stratégiák 
révén azok belseje, vagyis az objektumok módosításának két módját jelentik. 
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Homlokzat 


Szerkezeti objektumminta 


Egyéb nevek 

Facade, Arculat, Látszat 

Cél 

Egy alrendszerben felületek egy halmazához egységes felületet biztosítani. A módszerrel 


magasabb szintű felületet határozunk meg, amelynek révén az adott alrendszer könnyeb- 
ben használhatóvá válik. 


Feladat 


Ha egy rendszert alrendszerekre bontunk, csökkenthetjük annak bonyolultságát. Fontos 
tervezési célkitűzés, hogy az alrendszerek közötti függőségeket és kommunikációt a lehető 
legkevesebbre csökkentsük. Ennek elérésére az egyik megoldás, ha bevezetünk egy hom- 
lokzat objektumot, amely egyetlen egyszerűsített felületet ad az adott alrendszer általáno- 
sabb szolgáltatásai számára. 





























alrendszeri osztályok 























Vegyünk például egy programozási környezetet, amely hozzáférést biztosít az alkalmazá- 
sok számára a fordítói alrendszerhez. Ez az alrendszer olyan osztályokat tartalmaz, mint 
a Pásztázó (Scanner), az Elemző (Parser), a ProgramCsomópont (ProgramNode), a Bájtkód- 
Folyam (BytecodeStream), vagy a ProgramCsomópontÉpítő (ProgramNodeBuilder), ame- 
lyek megvalósítják a fordítót. Egyes alkalmazásoknak szükségük lehet ezen osztályok köz- 
vetlen elérésére, de a fordító legtöbb ügyfele nem törődik az olyan részletekkel, mint az 
elemzés vagy a kód-előállítás, csak valamilyen kódot szeretnének lefordítani. Számukra az 
erőteljes, de alacsonyszintű felületek a fordítói alrendszerben csak bonyolítják a feladatot. 


188 


4. fejezet " Szerkezeti minták 





Ahhoz, hogy az ügyfeleket ezen osztályoktól elszigetelő magasabb szintű felületet biztosít- 
hasson, a fordítói alrendszer egy Fordító (Compiler) nevű osztályt is tartalmaz, amely egy- 
séges felület határoz meg a fordító szolgáltatásaihoz. A Fordító osztály homlokzatként visel- 
kedik: az ügyfelek számára egyetlen egyszerű felületet nyújt a fordítói alrendszerhez, emel- 
lett összeragasztja a fordító szolgáltatásait megvalósító osztályokat, anélkül, hogy teljesen 
elrejtené azokat. A fordító homlokzata a legtöbb programozó dolgát megkönnyíti, miköz- 
ben nem rejti el azokat az alacsonyabb szintű szolgáltatásokat, amelyekre egyeseknek 


szükségük lehet, 








Ea Pásztázó . [- -i Token 


---mi —— Elemző Szimbólum 


el ProgramCsomópontéÉpítő £ - c ProgramCsomópont 
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VeremGépKódeElőállító ] [ RISCKódElőállító ] 











VáltozóCsomópont 








Alkalmazhatóság 


A Homlokzat minta alkalmazása a következő esetekben célszerű: 


s Egyszerű felületet szeretnénk nyújtani egy bonyolult alrendszerhez. Az alrendszerek 
a fejlesztés közben hajlamosak egyre összetettebbé válni, a legtöbb tervezési minta 
azonban több kisebb osztályt eredményez. Ezáltal az alrendszer jobban újrahaszno- 
sítható és könnyebben testreszabható lesz, de a testreszabást nem igénylő ügyfelek 
számára nehezebbé válik a használata. A homlokzat olyan egyszerű alapértelmezett 
nézetét adhatja az alrendszernek, ami a legtöbb ügyfél számára megfelel. Csak azok- 
nak az ügyfeleknek kell betekinteniük a homlokzat mögé, amelyek nagyobb testre- 
szabhatóságot igényelnek. 


Homlokzat 
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Az elvont fogalmat megvalósító osztályok és az ügyfelek között számos függőség áll 
fenn. A homlokzat bevezetésével az alrendszer elválasztható az ügyfelektől és más 
alrendszerektől, így függetlenebbé és hordozhatóbbá válik. 

Az alrendszereket rétegezni szeretnénk. Egy homlokzattal belépési pontot határoz- 
hatunk meg minden alrendszeri szinthez. Ha az egyes alrendszerek egymástól függ- 
nek, e függőségek egyszerűsíthetők, ha az alrendszerek csak homlokzatukon ke- 
resztül társaloghatnak egymással. 


Szerkezet 


Homlokzat 











Résztvevők 


Homlokzat (Fordító) 

— Tudja, mely alrendszeri osztályok felelnek egy adott kérelemért. 

— Az ügyfélkérelmek kezelését a megfelelő alrendszeri objektumokra ruházza át. 
alrendszeri osztályok (Pásztázó, Elemző, ProgramCsomópont stb.) 

— Megvalósítják az alrendszer szolgáltatásait. 

— Elvégzik a Homlokzat objektum által rájuk bízott feladatot. 

— Nincs tudomásuk a homlokzatról, vagyis nem hivatkoznak arra. 


Együttműködés 


Az ügyfelek úgy lépnek kapcsolatba az alrendszerrel, hogy kérelmeket küldenek 
a Homlokzatnak, ami aztán továbbítja azokat a megfelelő alrendszeri objektumhoz 
vagy objektumokhoz. Bár a tényleges munkát az alrendszeri objektumok végzik, 


a homlokzatnak is szüksége lehet bizonyos feladatok elvég; 
alrendszeri felületekhez igazítsa. 





ésére, hogy felületét az 


A homlokzatot használó ügyfeleknek nem kell közvetlenül elérniük az alrendszeri 
objektumokat. 
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Következmények 


A Homlokzat tervezési minta előnyei a következők: 


1. Elszigeteli az ügyfeleket az alrendszeri összetevőktől, így csökkenti azon objektu- 


mok számát, amelyekkel az ügyfeleknek foglalkozniuk kell, és megkönnyíti az al- 
rendszer használatát. 

Laza csatolást hoz létre az alrendszer és ügyfelei között. Az alrendszerek összetevői 
gyakran szoros csatolásúak, a laza csatolás révén azonban anélkül változtathatók, 
hogy ez hatással lenne az alrendszer ügyfeleire. A homlokzatok segítenek a rendszer 
rétegzésében, és az objektumok közti függőségek szabályozásában, megszüntetve 
a bonyolult vagy körkörös függőségeket, ami igen lényeges, ha az alrendszert és az 
ügyfelet egymástól függetlenül valósítjuk meg. 

A fordítási függőségek csökkentése létfontosságú a nagy szoftverrendszerekben, hi- 
szen ha az alrendszeri osztályok megváltozása nem von maga után nagy számú újra- 
fordítást, időt takaríthatunk meg. A függőségek homlokzatokkal való csökkentése 
korlátozza az újrafordítás szükségességét, ha egy fontos alrendszerben apró változás 
történik. A homlokzat emellett a rendszer más felületre történő átültetését is meg- 
könnyíti, mert használata mellett kevésbé valószínű, hogy egy alrendszer felépítése 
során az összes többi alrendszer felépítésére is szükség volna. 

Nem akadályozza meg, hogy az alkalmazások — ha szükségük van rá — használják az 
alrendszeri osztályokat, így választhatunk a használat könnyebbsége és a nagyobb 
általánosság között. 








Megvalósítás 


A Homlokzat minta megvalósítása során a következőkre kell figyelni: 


1. Az ügyfél-alrendszer csatolás csökkentése. Az ügyfelek és az alrendszer között fenn- 


álló csatolás tovább csökkenthető, ha a homlokzatot elvont osztállyá tesszük, amely 
az alrendszer különböző megvalósításaihoz konkrét alosztályokkal rendelkezik. Ek- 
kor az ügyfelek az elvont Homlokzat osztály felületén keresztül érintkezhetnek az 
alrendszerrel. Ez az elvont csatolás megakadályozza, hogy az ügyfelek tudomással 
bírjanak arról, hogy az alrendszer melyik megvalósítását használják. 

Az alosztályok származtatása helyett azt is megtehetjük, hogy a Homlokzat objektumot 
különböző alrendszeri objektumokkal állítjuk be. Ekkor a homlokzat testreszabásához 
egyszerűen csak ki kell cserélnünk egy vagy több alrendszeri objektumát. 

Nyilvános vagy privát alrendszeri osztályok? Az alrendszerek annyiban hasonlítanak az 
osztályokhoz, hogy nekik is van felületük, és egységbe zárnak valamit — az osztályok ál- 
lapotokat és műveleteket, az alrendszerek osztályokat. Ahogy pedig az osztályoknak 
van nyilvános és privát felületük, az alrendszerek is rendelkezhetnek ilyenekkel. 

Az alrendszerek nyilvános felülete olyan osztályokból áll, amelyeket minden ügyfél 
elérhet, míg a privát felület csak az alrendszert bővítő objektumok számára hozzáfér- 
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hető. A Homlokzat osztály természetesen a nyilvános felület része, de nem az egyet- 
len, más alrendszeri osztályok is nyilvánosak. A fordítói alrendszer Elemző és Pásztá- 
zó osztályai például szintén a nyilvános felület részei. 

Az alrendszeri osztályok nyilvánossá tétele hasznos lehet, mégis kevés objektumköz- 
pontú nyelv támogatja. A C4-4 és a Smalltalk hagyományosan globális névtérbe helyez- 
ték az osztályokat, de a C-t nyelvet szabványosító bizottság később a névterek hozzá- 
adásával lehetővé tette, hogy csak a nyilvános alrendszeri osztályokat fedjük fel. 


Példakód 


Nos, akkor nézzük meg, hogyan láthatunk el homlokzattal egy fordítói alrendszert. 


Az alrendszer meghatároz egy BytecodeStream (BájtkódFolyam) osztályt, amely egy 
Bytecode (Bájtkód) objektumokból álló adatfolyamot valósít meg. A Bytecode objektu- 
mok bájtkódokat zárnak egységbe, amelyek gépi utasításokat fogalmaznak meg. Az alrend- 
szer ezenkívül meghatároz egy Token nevű osztályt is azon objektumok számára, amelyek 
a programozási nyelv alapelemeit (token) zárják egységbe. 


A Scanner (Pásztázó) osztály egy karakterfolyamot vesz, és egyszerre egy elemet (token0 
vizsgálva tokenfolyammá alakítja azt. 


class Scanner ( 
public: 
Scanner (istreamg ) ; 


virtual "7Scannér() ; 


virtual Tokens Scan(); 
private: 

istream5 . inputStream; 
84 


A Parser (Elemző) osztály egy ProgramNodeBui 1lder (ProgramCsomópontÉpítő) segít- 
ségével elemzőfát épít fel a scanner tokenjeiből. 


class Parser ( 
public: 
Parser(); 


virtual "Parser(); 


virtual void Parse(Scannerg, ProgramNodeBuilderéő); 
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A Parser a ProgramNodeBuilder visszahívásával fokozatosan felépíti az elemzőfát. 
Ezek az osztályok az Építő mintát követve működnek együtt. 


class ProgramNodeBuilder ( 
public: 
ProgramNodeBuilder ( ) ; 


virtual ProgramNodet NewVariable( 
const char" variableName 
) const; 


virtual ProgramNodet NewAssignment ( 


ProgramNodetr variable, ProgramNodet expression 
) const; 


virtual ProgramNodet NewReturnStatement ( 
ProgramNode" value 
) const; 


virtual ProgramNoder NewCondition( 
ProgramNodet condition, 
ProgramNodet truePart, ProgramNodet falsePart 
) const; 
ÖV sees 


ProgramNodet GetRootNode (( ) ; 
private: 

ProgramNodetr node; 
b 


Az elemzőfát olyan ProgramNode (ProgramCsomópon?) alosztályok példányai építik fel, mint 
a StatementNode (UtasításCsomópont), az ExoressionNode (KifejezésCsomóponÓ) és így 
tovább. A ProgramNode hierarchia az Összetétel tervezési mintát követi. A ProgramNode 
a program-csomópont és esetleges gyermekei kezelésére határoz meg felületet. 


class ProgramNode ( 

public: 
7/ program-csomópont kezelése 
virtual void GetSourcePosition(inte line, intő index); 
Ess a 


7/ gyermekek kezelése 

virtual void Add(ProgramNodet ) ; 
virtual void Remove(ProgramNoder" ) ; 
ÉV ses 
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virtual void Traverse (CodeGenerator€ ) ; 
protected: 

ProgramNode ( ) ; 
1; 


A Traverse (Bejár) művelet egy CodeGenerator (KódElőállító) objektumot vesz, amit 
a ProgramNode alosztályok arra használnak, hogy gépi kódot állítsanak elő egy 
BytecodeStream Bytecode objektumai formájában. A CodeGenerator osztály maga 
egy látogató (lásd a Látogató mintát az 5. fejezetben). 


class CodeGenerator ( 
public: 
virtual void Visit(StatementNode" ) ; 
virtual void Visit(ExpressionNodet ) ; 
$7e439 
protected: 
CodeGenerator (BytecodeStreamet ) ; 
protected: 
BytecodeStream5g . output ; 
1; 


A CodeGenerator olyan alosztályokkal rendelkezik, mint a StackMachineCode- 
Generator (VeremGépkKódElőállító) vagy a RISCCodeGenerator (RISCKódElőállító), 
amelyek különböző hardver-architektúrák számára állítanak elő gépi kódot. 


A ProgramNode valamennyi alosztálya megvalósítja a Traverse műveletet, hogy meg- 
hívja azt gyermekobjektumaira. A gyermekobjektumok azután ugyanígy meghívják a mű- 
veletet saját gyermekeikre, és így tovább. Az ExpressionNode például a következőkép- 
pen határozza meg a Traverse műveletet: 


void ExpressiónNode: : Traverse (CodeGeneratorg cg) ( 
cg.Visití(this); 


ListlteratorcProgramNodet; i( children) ; 


for (i.First(); !i.IsDone(); i.Next()) ( 
i.CurrentItem( ) sTraverse(cg) ; 


Az eddig tárgyalt osztályok építik fel a fordítói alrendszert. Most bevezetünk egy Compiler 
(Fordító) nevű homlokzatosztályt, amely összefogja a rendszer részeit. A Compiler egy- 
szerű felületet biztosít a forrás lefordítására, és az adott gépfelépítésnek megfelelő kód elő- 
állítására. 


e] 
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class Compiler ( 
public: 
Compiler(); 


virtual void Compile(istreams, BytecodeStream6 ) ; 
b; 


void Compiler::Compile ( 
istreamá input, BytecodeStreamg output 
) 1 
Scanner scanner(input) ; 
ProgramNodeBuilder builder; 
Parser párser; 


parser.Parse(scanner, builder); 


RISCCodeGenerator generator (output) ; 
ProgramNodet parseTree - builder.GetRootNode( ) ; 
parseTree-5sTraverse (generator) ; 


Ez a megvalósítás mereven bekódolja a használandó kód-előállító típusát, így a programo- 
zóknak nem kell megadniuk a cél-architektúrát. Ez a megoldás akkor ésszerű, ha csak 
egyetlen célgéptípus lehetséges. Ha viszont nem ez a helyzet, a compiler konstruktorát 
úgy kell megváltoztatnunk, hogy egy CodeGenerator paramétere legyen, így a progra- 
mozók a Compiler példányosításakor meghatározhatják a használandó kód-előállítót. 
A fordító homlokzata más résztvevőket is paraméterré tehet, például a Scanner-t és 
a ProgramNodeBuilder-t, ami növeli a rugalmasságot, de eltávolodik az eredeti céltól, 
ami általában a felület egyszerűsítése. 


Ismert felhasználások 


A Példakód részben szereplő fordító az ObjectWorkstSmalltalk fordítórendszerén [Par90] 
alapult. 


Az ET$t alkalmazás-keretrendszerben IVGM88] az alkalmazások beépített böngészővel 
vizsgálhatják objektumaikat futás közben. Ezek a böngészők önálló alrendszerekben kap- 
nak helyet, ami egy ,ProgrammingEnvironment" (programozási környeze) nevű homlok- 
zatosztályt tartalmaz, Ez a homlokzat a böngészők elérésére szolgáló műveleteket ( például 
InspectObject, InspectClass) határozza meg. 


Az ETtt alkalmazások ,hamisíthatják" is a beépített böngészőtámogatást. Ilyen esetben 
a ProgrammingEnvironment a kérelmeket null-műveletekként valósítja meg, vagyis azok 
nem csinálnak semmit. Csak az ETProgrammingEnvironment alosztály ad olyan megvalósí- 
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tást a kérelmekhez, amely meghatározza a megfelelő böngészőket megjelenítő műveleteket. 
Az alkalmazásnak nincs tudomása arról, hogy jelen van-e egy elérhető böngészőkörnyezet, 


vagyis az alkalmazás és a böngésző alrendszer között elvont csatolás áll fenn. 


A Choices operációs rendszer ICIRM93] arra használ homlokzatokat, hogy több keretrend- 
szert egyesítsen. A Choices kulcsfogalmai a folyamat (process), a tárolás (storage) és a cím- 
tér (address space). Mindegyikhez tartozik egy keretrendszerként megvalósított alrendszer, 
amely támogatja a Choices különböző hardverfelületekre történő átültetését. Az alrendsze- 
rek közül kettőnek van , képviselője" (vagyis homlokzata); ezek neve FileSysteminterface 


(FájlkendszerFelület, tárolás), illetve Domain (Tartomány, címterek). 














AddressTranslation 





FindMemory(Address) 








TwoLevelPageTable 








A virtuális memória keretrendszernek például a Domain (Tartomány) a homlokzata, A tar- 
tományok egy-egy címteret képviselnek, és a virtuális címek és eltolások memória-objektu- 
mokra vagy fájlokra való leképezését biztosítják. A Domain fő műveletei arra szolgálnak, 
hogy egy memória-objektumot elhelyezzünk egy adott címen, eltávolítsunk egy ilyen ob- 





Process Ae ed Domain 


Add(Memory, Address) 
Remove(Memory) 


RepairFault() 


Protect(Memory, Protection) 











MemoryObject 





BuildCache() 





FA eg 


MemoryObjectCache 





A 


PersistentStore 


b 








PagedMemoryObjectCache 








FAN 











File ] Disk 








jektumot, illetve kezeljünk egy laphibát. 


Amint a fenti diagram is mutatja, a virtuális memória alrendszer belül a következő összete- 


vőkből áll: 


e  MemoryObject (MemóriaObjektum, egy adattárat képvisel); 
s  MemoryObjectCache (MemóriaObjektumTár, a memória-objektumok adatait átme- 
netileg a fizikai memóriában tárolja; valójában egy stratégia, amely az átmeneti táro- 


lás módját zárja egységbe); 


e  AddressTranslation (CímFordítás, a címfordító hardvert zárja egységbe). 
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Amikor egy laphiba miatti megszakítás következik be, a RepairFault (JavítHiba) művelet hí- 
vódik meg. A Domain megkeresi a hibát okozó címen levő memória-objektumot, és az ah- 
hoz rendelt átmeneti tárra bízza a RepairFault végrehajtását. A tartományok összetevőik 
megváltoztatásával testreszabhatók. 


Kapcsolódó minták 


A Homlokzat mintával együtt használható az Elvont Gyár, így felületet biztosíthatunk az al 
rendszeri objektumok alrendszertől független létrehozására. Az Elvont Gyár a rendszerfüg- 
gő osztályok elrejtésében is helyettesítheti a Homlokzat mintát. 


A Közvetítő minta annyiban hasonlít a Homlokzatra, hogy szintén meglevő osztályok szol 
gáltatásait vonatkoztatja el. A Közvetítő célja azonban a társobjektumok kapcsolattartásá. 
nak elvonttá tétele, gyakran az olyan szolgáltatások központosításával, amelyek egyik ob 
jektumhoz sem tartoznak. A közvetítő kollégái ismerik a közvetítőt, és az egymás köz. 
közvetlen kommunikáció helyett vele társalognak. A homlokzat ezzel szemben csupán el- 
vonttá teszi az alrendszeri objektumok felületét, hogy megkönnyítse használatukat; új szo. 
gáltatásokat nem határoz meg, az alrendszeri osztályok pedig nem tudnak róla. 














Általában csak egyetlen homlokzatobjektumra van szükség, így a homlokzatok gyakran 
Egykék. 


Pehelysúlyú 


Szerkezeti objektumminta 


Egyéb nevek 
Flyweight, Könnyűsúlyú 
Cél 


Megosztás révén támogatni a nagy finomságú objektumok tömegeinek hatékony fel- 
használását. 


Feladat 


Egyes alkalmazások nyerhetnek azon, ha mindenre külön objektumot használnak, de egy 
naiv megvalósítás igen költséges lehet. 


A legtöbb dokumentum- vagy szövegszerkesztő például bizonyos fokig modularizált szö- 
vegformázó és —szerkesztő képességekkel rendelkezik. Az objektumközpontú szövegszer- 
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kesztők jellemzően objektumokkal ábrázolják az olyan beágyazott elemeket, mint a táblá- 
zatok és ábrák. A dokumentum egyes karaktereit azonban már nem önálló objektumok 
képviselik, még ha ez a program legfinomabb szintjén is jelentene rugalmasságot. Ha így 
lenne, a karaktereket és beágyazott elemeket egységesen kezelhetnénk, kirajzolási és for- 
mázási módjuktól függően. A program anélkül lenne bővíthető új karakterkészletek támo- 
gatásával, hogy a többi szolgáltatásra ez hatással lenne. Az alkalmazás objektumszerkezete 
pontosan tükrözhetné a dokumentum , fizikai" szerkezetét. Az alábbi diagram azt mutatja, 
hogyan jelölhet karaktereket objektumokkal egy szövegszerkesztő: 





ú karakter 
. objektumok 
0.0 e... sor 
SD. Pair em objektumok 
: hasáb 


Ni objektumok 


A módszer hátulütője a magas költség. Még a szerényebb méretű dokumentumok is karak- 
ter objektumok százezreit igényelnék, ami rengeteg memóriát emésztene fel, a futási sebes- 
ség pedig elfogadhatatlan szintre csökkenne. A Pehelysúlyú minta azonban megmutatja, 
hogyan oszthatunk meg objektumokat finomabb szinten való használatra anélkül, hogy 
a költségek az egekbe szöknének. 


A pehelysúlyú objektum olyan megosztott objektum, amely egyidejűleg több környezetben 
használható. Mindegyik környezetben önálló objektumként viselkedik, vagyis nem különböz- 
tethető meg egy nem megosztott objektum példányától, és nem élhet feltételezésekkel műkö- 
dési környezetéről. A minta kulcsa a belső és külső állapot(információk) megkülönböztetése. 
A belső állapot a pehelysúlyú objektumban tárolódik, és olyan információkból áll, amelyek 
függetlenek a pehelysúlyú objektum környezetétől, így megoszthatók. A külső állapot ezzel 
szemben a környezettől függően változik, ezért megosztása nem lehetséges. Az ügyfélobjektu- 
mok feladata, hogy külső állapotot adjanak át a pehelysúlyú objektumnak, amikor az igényli. 


A pehelysúlyú objektumok olyan fogalmakat vagy egyedeket modelleznek, amelyek száma 
normális esetben túl nagy ahhoz, hogy objektumokkal ábrázolhatók legyenek. Egy szöveg- 
szerkesztőben például az ábécé minden betűjéhez létrehozhatunk egy-egy pehelysúlyú ob- 
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jektumot. Ezek csak egy karakterkódot tárolnak; a dokumentumban elfoglalt helyet és 
a betűstílust a szöveg-elrendező algoritmusok és a karakter megjelenési helyén érvényben 
levő formázási parancsok alapján határozzuk meg. A karakterkód belső állapotinformáció, 
míg a többi információ külső. 


Logikailag a dokumentum egy adott karakterének minden előfordulásához létezik egy 
objektum: 





Fizikailag azonban karakterenként egy megosztott pehelysúlyú objektummal rendelke- 
zünk, amely különböző környezetekben jelenik meg a dokumentumszerkezetben. Egy 
adott karakter objektum valamennyi előfordulása ugyanarra a példányra hivatkozik a pe- 


helysúlyú objektumok megosztott gyűjtőtárában: 





pehelysúlyú készlet 


; 
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A fenti objektumok osztályszerkezetét a következő ábrán mutatjuk be. A Képjel (Glyph) 






































a grafikus objektumok elvont osztálya, amelyek közül néhány pehelysúlyú lehet; a külső álla- 
poton alapuló műveletek paraméterként kapják meg. A Rajzol (Draw) és a Metszi (Intersects) 
műveleteknek például tudniuk kell, milyen környezetben van a képjel, mielőtt elvégezhetnék 
munkájukat. 
se Képjel 10-a 
RajzolfKörnyezet) 
Metszi(Pont, Környezet) 
] 
Sor ] Karakter ! Hasáb 
i Gyertbekek  Razölíköríyozat) Rajzolíkörnyezet) Rajzol(környezet) jákásá 
Metszi(Pont, Környezet) Metszi(Pont, Környezet) Metszi(Pont, Környezet) 














char c 





Az ,a" betűt képviselő pehelysúlyú objektum csak a megfelelő karakterkódot tárolja, a he- 
yet vagy a betűtípust nem. Az objektum kirajzolásához szükséges környezetfüggő informá- 
ciókat az ügyfelek adják át. Egy Sor (Row) képjel például tudja, hogy gyermekeinek hol 
kell kirajzolniuk magukat, hogy egy sorban helyezkedjenek el, így a rajzolási kérelemben 
átadhatja nekik a helyüket. 


Mivel a különböző karakter objektumok száma jóval kisebb, mint a dokumentumban levő 
karaktereké, lényegesen kevesebb objektumunk lesz, mint amennyit egy naiv megvalósí- 
tásban használnánk. Egy egyetlen betűtípussal és színnel írt dokumentum 100 karakter ob- 
jektum sorrendje alapján előállítható (ez durván az ASCII karakterkészlet mérete), függetle- 
nül a dokumentum hosszától, és mivel a legtöbb dokumentum nem használ tíznél több 
Detűtípus-szín kombinációt, az említett szám a gyakorlatban nem nő jelentősen. Így válik 
az objektum alapú megközelítés önálló karakterek esetében is hasznosíthatóvá. 








Alkalmazhatóság 





A Pehelysúlyú minta hatékonysága nagyban függ attól, hol és hogyan használjuk. Csak ak- 
kor alkalmazzuk, ha az alábbi állítások mindegyike igaz: 


e Az alkalmazás nagy számú objektumot használ. 

. Az objektumok nagy száma miatt magas a tárköltség. 

e A legtöbb objektum-tulajdonság (állapoD) külsővé tehető. 

, A Kkülső állapot eltávolítása után objektumok egész csoportjai helyettesíthetők vi- 
szonylag kevés megosztott objektummal. 

e Az alkalmazás nem az objektumok azonosságán alapul. Miután a pehelysúlyú objek- 
tumok megoszthatók, egy azonosságvizsgálat fogalmilag különböző objektumok 
esetében is , igaz" eredményt adhat. 
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Szerkezet 













if (pehelysúlyúlkulcs) létezik ( 
retum létező pehelysúlyú; 


) else ( 
létrehoz új pehelysúlyú; 
hozzáad to pehelysúlyú tár; 
retum új pehelysúlyú; 

















KonkrétPehelysúlyú 
MűveletíkülsőÁllapot) 


NemkMegosztottkonkrétPehelysúlyú 
MűveletíkülsőÁllapot) 














belsőÁllapot mindenÁllapot 











Ügyfél 


A következő objektumdiagram a pehelysúlyú objektumok megosztásának módját mutatja: 


egű 
mega pina 




















egyPehelysúlyúGyár Tr egyKonkrétPehelysúlyú jú egyKonkrétPehelysúlyú . ) 
pehelysúlyúak fe belsőÁllapot J A belsőÁllapot ) 
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Résztvevők 

e  Pehelysúlyú (KépjeD 

— Felületet vezet be, amelyen keresztül a pehelysúlyú objektumok külső állapotin- 
formációkat fogadhatnak, és azok alapján műveleteket végezhetnek. 

e  KonkrétPehelysúlyú (Karakter) 

— Megvalósítja a Pehelysúlyú (Flyweight) felületet és tárat biztosít az esetleges belső 
állapotinformációk számára. A KonkrétPehelysúlyú (ConcreteFlyweight) objektu- 
moknak megoszthatóknak kell lenniük, a bennük tárolt állapotnak pedig belsőnek 

kell lennie, vagyis függetlennek a KonkrétPehelysúlyú objektum környezetétől, 
s  NemMegosztottkKonkrétPehelysúlyú (Sor, Hasáb) 

—- Nem minden Pehelysúlyú alosztálynak kell megoszthatónak lennie. A Pehelysú- 
yú felület csak lehetővé teszi a megosztást, nem kényszerít rá. A NemMegosz- 
tottKonkrétPehelysúlyú (UnsharedConcreteFlyweight) objektumok (ahogy a Sor 
és Hasáb - Row, Column — osztályok is) gyakran rendelkeznek Konkrét- 
Pehelysúlyú gyermekobjektumokkal a pehelysúlyú objektumszerkezet valamely 
szintjén. 

s  PehelysúlyúGyár 

— Pehelysúlyú objektumokat hoz létre és kezel. 

- Gondoskodik a pehelysúlyú objektumok megfelelő megosztásáról. Amikor egy 
ügyfél pehelysúlyú objektumot kér, a PehelysúlyúGyár (FlyweightFactory) átad 
egy meglevő példányt, vagy létrehoz egyet, ha még egy sem létezik. 

e Ügyfél 
— Hivatkozást tart fenn egy vagy több pehelysúlyú objektumra. 
— Kiszámítja vagy tárolja a pehelysúlyú objektum(ok) külső állapotát. 





Együttműködés 


e A pehelysúlyú objektumok által igényelt állapotinformációk belsők vagy külsők le- 
hetnek. A belső állapotot a KonkrétPehelysúlyú objektum tárolja, a külső állapot tá- 
rolásáról, illetve kiszámításáról az Ügyfél (ClienO objektumok gondoskodnak. 
Az ügyfelek akkor adják át a külső állapotot a pehelysúlyú objektumnak, amikor 
meghívják annak műveleteit. 

e Az ügyfeleknek nem szabad közvetlenül példányosítaniuk a KonkrétPehelysúlyú 
objektumokat. Kizárólag a PehelysúlyúGyár objektumtól szerezhetik be azokat, 
hogy megosztásuk megfelelő legyen. 


Következmények 


A pehelysúlyú objektumok a külső állapotinformációk átvitele, megkeresése, illetve kiszá- 
mítása miatt lassíthatják a program futását, különösen ha a külső állapot korábban belső ál- 
lapotként tárolódott. Ezt a költséget azonban ellensúlyozza a tárhely-megtakarítás, ami egy- 
re nagyobb lesz, ahogy több pehelysúlyú objektumot osztunk meg. 
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A tárhely-megtakarítás több tényezőtől függ: 


e a példányok számának a megosztásból következő csökkenésétől, 
s az objektumonkénti belső állapotinformációk mennyiségétől, valamint 
e attól, hogy a külső állapotot kiszámítjuk vagy tároljuk. 


Minél több pehelysúlyú objektumot osztunk meg, annál több helyet takarítunk meg, és 
a megtakarítás a megosztott állapotinformációk mennyiségének növelésével tovább növel- 
hető. A legtöbbet akkor nyerünk, ha az objektumok jelentős mennyiségű belső és külső ál- 
lapotinformációt használnak fel, a külső állapotot pedig számítjuk, és nem tároljuk. A szük- 
séges tárhely így két módon csökken: a megosztás a belső állapot tárolási költségét csök- 
kenti, míg a külső állapotét , elcseréljük" a kiszámításához szükséges időre. 


A Pehelysúlyú mintát gyakran együtt használják az Összetétel mintával, hogy egy hierarchi- 
kus szerkezetet egy olyan gráffal ábrázoljanak, amelynek megosztott levél-csomópontjai 
vannak. A megosztás egyik következménye, hogy a pehelysúlyú levél-csomópontok nem 
tárolhatnak mutatót szülőjükre; helyette a külső állapot részeként kapják meg a szülőmuta- 
tót, ami lényegesen befolyásolja, hogy a hierarchia objektumai hogyan kommunikálnak 
egymással. 





Megvalósítás 


A Pehelysúlyú minta megvalósítása során a következőkre kell figyelnünk: 


1. A külső állapot eltávolítása. A minta alkalmazhatóságát nagy részben az határozza 
meg, mennyire egyszerű a külső állapotinformációk azonosítása és eltávolítása 
a megosztott objektumokból. A külső állapot eltávolítása ugyanis nem segít a tárkölt- 
ség csökkentésében, ha ugyanolyan sokféle külső állapotinformáció létezik, mint 
objektum (a megosztás előtt). Ideális esetben a külső állapot egy önálló objektum- 
szerkezetből számítható ki, amelynek jóval kisebb a tárigénye. 
Szövegszerkesztőnkben például a tipográfiai információk , térképét" külön szerke- 
zetben tárolhatjuk, ahelyett, hogy a betűtípust és -stílust tárolnánk minden egyes ka- 
rakter objektumhoz. A , térkép" nyomon követi az azonos tipográfiai jellemzőkkel írt 
karaktereket; amikor egy karakter kirajzolja önmagát, ezeket a jellemzőket a rajzolá- 
si bejárás , mellékhatásaként" kapja meg. Mivel a dokumentumok általában csak né- 
hány betűtípust és -stílust használnak, ezen információk külső tárolása az egyes ka- 
rakter objektumok számára jóval hatékonyabb, mint a belső tárolás. 
2. A megosztott objektumok kezelése. Mivel az objektumokat megosztjuk, az ügyfelek- 
nek nem szabad közvetlenül példányosítaniuk azokat. Egy adott pehelysúlyú objek- 
tum megkeresését a PehelysúlyúGyár teszi lehetővé az ügyfelek számára. 
A PehelysúlyúGyár objektumok gyakran egy társításos tárat (asszociatív tárat) hasz- 
nálnak, hogy az ügyfelek megkereshessék a számukra érdekes pehelysúlyú objektu- 











Pehelysúlyú 


203 





mokat. A szövegszerkesztő pehelysúlyúobjektum-gyára például egy karakterkódok- 
kal indexelt táblázatot tarthat fenn, amelyből a kezelő a kód alapján visszaadja a meg- 
felelő pehelysúlyú objektumot, létrehozva azt, ha még nem létezik. 

A megoszthatóság maga után von valamiféle hivatkozás-számlálást vagy szemétgyűj- 
tést is, hogy felszabadíthassuk a pehelysúlyú objektumok által elfoglalt tárat, amikor 
már nincs rájuk szükség. Mindazonáltal egyikre sincs szükség, ha a pehelysúlyú objek- 
tumok száma kicsi és rögzített (ilyenek például az ASCII karakterkészlet pehelysúlyú 
objektumai) — ilyenkor érdemes az objektumokat mindig a kezünk ügyében tartani. 


Példakód 


Térjünk vissza a dokumentumformázó példához, amelyben most egy Glyph (Képjel) nevű 
alaposztályt határozunk meg a pehelysúlyú grafikus objektumok számára. Logikailag 
a képjelek összetételek (lásd az Összetétel mintáj), amelyeknek grafikai jellemzőik vannak, 
és képesek kirajzolni önmagukat. Mi most csak a betűtípus jellemzőre összpontosítunk, de 
ugyanez a megközelítés alkalmazható bármely más grafikai jellemzőre, amellyel egy képjel 
rendelkezhet. 


class Glyph ( 
public: 


virtual "Glyph(); 
virtual void Draw(Windowt, GlyphContext6); 


virtual void SetFont(Foöntt, GlyphContext£); 
virtual Fontt GetFont (GlyphContext6£) ; 


virtual void First (GlyphContext6£) ; 
virtual void Next ((GlyphContext6£) ; 
virtual bool IsDone(GlyphContext6) ; 
virtual Glyph" Current ((GlyphContext6) ; 


virtual void Insert(Glypht, GlyphContext65); 
virtual void Remove(GlyphContext6) ; 
protected: 
Glyph() ; 
pi 


A Character (Karakter) alosztály csak egy karakterkódot tárol: 


class Character : public Glyph ( 
public: 
Character (char) ; 
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virtual void Draw(Windowt, GlyphContext£6£) ; 
private: 

char  charcode; 
1; 


Ahhoz, hogy elkerülhessük, hogy minden egyes képjel betűtípus jellemzőjének helyet fog- 
laljunk, a jellemzőt külsőleg, egy GlyphContext (KépjelkörnyezeD) objektumban tároljuk. 
A GlyphContext a külső állapotinformációk raktáraként működik. Tömören egymáshoz 
rendeli a képjeleket és betűtípusukat (illetve bármilyen más lehetséges grafikai jellemzőjü- 
ket) a különböző környezetekben. Minden művelet, amelynek szüksége van arra, hogy is- 
merje a képjel betűtípusát egy adott környezetben, paraméterként egy GlyphContext 
példányt kap, amelytől elkéri a környezetben érvényes betűtípust. A környezet a képjelnek 
a képjelszerkezetben elfoglalt helyétől függ, ezért a Glyph gyermekbejáró és -kezelő mű- 
veleteinek minden használat után frissíteniük kell a GlyphContext-et. 


class GlyphContext ( 
public: 
GlyphContext ( ) ; 


virtual 7GlyphContext ( ) ; 


virtual void Next(int step - 1); 
virtual void Insert(int auantity - 1); 


virtual FontY GetFont ( ) ; 

virtual void SetFont(Fontt, int span - 1); 
private: 

int . index; 

BTreet  fonts; 


); 


A GlyphContext-nek mindig tudnia kell, hol jár a képjelszerkezetben. Ahogy a bejárás 
halad, a GlyphContext : :Next növeli az index-et. A Glyph gyermekekkel rendelkező 
alosztályai (például a Row vagy a Column) úgy kell, hogy megvalósítsák a Next (Követke- 
ző) műveletet, hogy az a bejárás minden pontján meghívja a GlyphContext : : Next-et. 


A GlyphContext : : GetFont (Képjelkörnyezet::SzerezBetűtípus) az indexet egy BTree 
(B-fa) szerkezet kulcsaként használja, amely a képjel-betűtípus hozzárendeléseket tárolja. 
A fa minden csomópontját annak a karakterláncnak a hossza címkézi, amelyhez az adott 
csomópont betűtípus-információt ad. A fa levelei egy-egy betűtípusra mutatnak, míg a bel- 
ső csomópontok részláncokra tördelik a karakterláncokat. Minden gyermekhez egy-egy 
részlánc tartozik. 
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Vegyük az alábbi részletet egy képjel-összetételből: 


2 3 4 5 6 T B 9 140 tt 12 13 14 15 16 17 18 19 20 


Object-oriented PT.ög es 


95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 Tt 112113 


wz people zexpeci :tor eh esse 


299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 217 


se an iterator Foo can "e 


A BTree szerkezet valahogy így festhet: 
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A belső csomópontok képjel-indextartományokat határoznak meg. Ha a betűtípus megvál- 
tozik, a szerkezethez képjeleket adunk, vagy képjeleket veszünk el onnan, a BTree frissül, 
Tegyük fel például, hogy a bejárás során a 102-es sorszámnál (indexnél) tartunk. Ekkor az 
alábbi kód az ,expect" szó minden karakterét a környező szöveg betűtípusára (times12, 
ami a Font példánya a 12 pontos Times Roman betűkhöz) állítja: 


GlyphContext gc; 


Fontt times12 - new Font ("Times-Roman-12") ; 


Föntt timesltalici2 - new Font ("Times-Italic-12"); 
ÉVves 


gc.SetFont(times12, 6); 


Az új BTree szerkezet a következőképpen néz ki (a változást kiemeltük): 


Times 12 es-B SOLTBT 


Tegyük fel, hogy az expect" elé beszúrjuk a ,don" szót (egy szóközzel együti), 12 pontos 
Times-Italic (dől) betűvel. Az alábbi kód értesíti a gc-t az eseményről, feltételezve, hogy 
még mindig a 102-es indexen tartózkodik: 


gc.Insert (6) ; 
gc.SetFont(timesíltalici2, 6); 
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A BTree szerkezet ekkor így módosul: 


1 Times-ltalic 12 


Amikor a GlyphContext-től elkérik az aktuális elem betűtípusát, végighalad a B-fán, amíg 
meg nem találja az aktuális indexnek megfelelő betűtípust. Miután a betűtípus-váltások szá- 
ma viszonylag csekély, a fa a képjelszerkezet méretéhez képest kicsi marad, ami alacso- 
nyan tartja a tárköltséget, anélkül, hogy aránytalanul nőne a keresési idő." 





Az utolsó objektum, amire szükségünk van, egy PehelysúlyúGyár, amely létrehozza a kép- 
jeleket és gondoskodik megfelelő megosztásukról. A GlyphFactory (KépjelGyár) osztály 
Character és más típusú képjeleket példányosít. Csak a Character objektumokat oszt- 
juk meg; az összetett képjelekből jóval kevesebb van, és fontosabb állapotinformációik 
(például a gyermekekre vonatkozók) amúgy is belsők. 


const int NCHARCODES - 128; 


class GlyphFactory ( 
public: 
GlyphFactory () ; 


virtual "7GlyphFactory ( ) ; 


virtual Charactert CreateCharacter(char) ; 
virtual RowYt CreateRowt(); 

virtuál Columnt CreateColumn(( ) ; 

EE. es 





5 A keresési idő ebben a sémában a betűtípus-váltások gyakoriságával arányos. A teljesítnény akkor a leg- 
rosszabb, ha minden karakterre jut egy betűtípus-váltás, de ez a gyakorlatban szokatlan lenne. 
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private: 
Charactert . character [NCHARCODESI ; 
1; 


A character tömb karakterkóddal indexelt Character képjeleket címző mutatókat tar- 
talmaz. A tömb a konstruktorban nulla kezdőértéket kap. 


GlyphFactory : :GlyphFactory () ( 
for (int - 0; i c NCHARCODES; 44-i) ( 
.character[i)] - 0; 


) 
) 


A CreateCharacter (LétrehozKarakter) megkeres egy karaktert a tömbben levő képjel- 
ben, és visszaadja a megfelelő képjelet, ha létezik. Ha nem létezik, létrehozza, a tömbbe 
helyezi, majd ezután adja vissza: 


Charactert GlyphFactory: :CreateCharacter (char c) ( 
if (! character[c]) ( 
.character[c] - new Character(c); 


) 


return . character[c] ; 
) 


A többi művelet egyszerűen egy új objektumot példányosít minden híváskor, mivel a nem 
karakter képjeleket nem osztjuk meg: 


Rowt GlyphFactory: :CreateRow () ( 
return new Row; 


) 


Columnt GlyphFactory::CreateColumn () ( 
return new Column; 


) 


Ki is hagyhatnánk ezeket a műveleteket, és a meg nem osztott képjelek példányosítását 
közvetlenül az ügyfélre bízhatnánk, de ha később úgy döntünk, hogy mégis megosztható- 
vá tesszük őket, módosítanunk kell létrehozó kódjukat az ügyfélben. 


Ismert felhasználások 


A pehelysúlyú objektumok ötletét először az InterViews 3.0 [CL90] írta le és aknázta ki ter- 
vezési módszerként. Fejlesztői bizonyítékként egy erőteljes szövegszerkesztőt (Doc) is el- 
készítettek ICL92]. A Doc a dokumentumok valamennyi karakterét képjel (Glyph) objektu- 
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mokkal ábrázolja. A szerkesztő minden karakter számára, amelyet egy adott (a grafikai jel- 
lemzőket meghatározó) stílussal írtak, külön Glyph példányt épít, így a karakterek belső ál- 
lapota a karakterkódból és a stílusinformációból (egy stílustáblázat adott indexéből) áll." 
Ez azt jelenti, hogy csak a karakter helye külső információ, aminek révén a Doc működése 
gyors. A dokumentumokat a Document (Dokumentum) osztály jelképezi, amely egyben 
a PehelysúlyúGyár szerepét is betölti. A Doc vizsgálata azt mutatta, hogy a pehelysúlyú ka- 
rakterek megosztása igen hatékony: egy átlagos, 180 000 karakterből álló dokumentum 
mindössze 480 karakter objektum számára igényel tárhelyet. 


Az ET IWGM88] a megjelenítési szabványoktól való függetlenséget támogatja pehelysú- 
lyú objektumokkal." A megjelenítési szabványok a felhasználói felület elemeinek (gördí- 
tősávok, gombok, menük — egységes nevükön vezérlők) megjelenését, illetve azok (árnyé- 
kolással, térhatással való) díszítését szabályozzák. A vezérlők ezeket a feladatokat (elrende- 
zés, kirajzolás) egy önálló Layout (Elrendezés) objektumra ruházzák át, amelynek megvál- 
toztatásával akár futásidőben módosítható a megjelenítési mód. 


Minden vezérlőosztályhoz egy-egy Layout osztály tartozik (ScrollbarLayout, Menubar- 
Layout stb.). A megoldással nyilvánvalóan az a gond, hogy a felhasználói felület objektu- 
mainak száma megkétszereződik. Ezt a terhelést elkerülendő a Layout objektumok pehely- 
súlyúak. Ez természetesen adódik, hiszen ezen objektumok feladata többnyire valamilyen 
viselkedés meghatározása, az elrendezéshez és rajzoláshoz szükséges csekély mennyiségű 
külső állapotinformáció pedig könnyen átadható nekik. 


A Layout objektumokat Look (Kinéze) objektumok hozzák létre és kezelik. A Look osztály 
egy elvont gyár, amely a megfelelő Layout objektumot olyan műveletekkel állítja elő, mint 
a GetButtonLayout (SzerezGombElrendezés), GetMenuBarLayout (SzerezMenüSorElren- 
dezés) és így tovább. Minden megjelenítési szabványhoz tartozik egy Look alosztály 
(MotifLook, OpenLook stb.), amelyek a megfelelő Layout objektumokat biztosítják. 


A Layout objektumok egyébiránt lényegüket tekintve stratégiák (lásd a Stratégia mintát), 
vagyis olyan stratégia objektumok, amelyeket pehelysúlyúként valósítottak meg. 


Kapcsolódó minták 
A Pehelysúlyú mintát gyakran használják együtt az Összetétel mintával, hogy egy megosz- 


tott levél-csomópontokkal rendelkező irányított körmentes gráf formájában valósítsanak 
meg egy hierarchikus logikai szerkezetet. 


Az Állapot és a Stratégia minta objektumait általában pehelysúlyúként a legjobb megvalósítani. 





4 A Példakód részben szereplő kódban a stílusinformáció külső, csak a karakterkód belső állapotinformáció, 


5 A megjelenítési szabványoktól való függetlenség biztosítására egy másik megközelítést az Elvont Gyár mintánál 
találhatunk. 
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Helyettes 


Szerk: 
Cél 


Adott 
ügyel 


ezeti objektumminta 


objektumot képviselőn vagy helyőrzőn keresztül irányítani, hogy szorosabban fel- 
hessük működését. 


Egyéb nevek 


Proxy, Surrogate (Helyettesítő) 


Feladat 


kerü 
jektur 





Az objektumokhoz való hozzáférés szabályozásának egyik célja, hogy létrehozásuk és elő- 


jük teljes költségének , megfizetését" elhalasszuk addig, amíg ténylegesen sor nem 
használatukra, Vegyünk egy szövegszerkesztő programot, amely képes grafikus ob- 
mokat beágyazni egy dokumentumba. Egyes grafikus objektumok — például a nagy- 


méretű raszterképek — létrehozása igen költséges lehet. A dokumentum megnyitásának 
azonban gyorsnak kell lennie, ezért el kell kerülnünk azt, hogy a költséges objektumokat 
a dokumentum megnyitásakor, egyszerre hozzuk létre. Erre egyébként sincs szükség, hi- 
szen egyidejűleg nem mindegyik objektum látható a dokumentumban. 





Mindezekből az következik, hogy a költséges objektumokat igény szerint kell létrehoz- 
nunk, vagyis ebben az esetben akkor, amikor az adott kép láthatóvá válik. De addig mit te- 
gyünk a helyére a dokumentumban, és hogyan rejtsük el azt a tényt, hogy a kép igény sze- 


rint jön létre, anélkül, hogy túlbonyolítanánk a szerkesztő megvalós; 





? Csak hogy egy 


példát említsünk, a létrehozás optimalizálásának nem szabad hatással lennie a megjeleníté- 
si és formázási kódra. 


A me: 


goldás egy új objektum, a képhelyettes használata, amely a tényleges kép helyén áll. 


A helyettes ugyanúgy viselkedik, mint maga a kép, és gondoskodik annak példányosításá- 
ról, ha szükség van rá. 





egySzövegDokumentum 








egyKépHelyettes 


fájlNév 








egyKép 









erez zs elemez ae 





adatok 


18 SÉRE a memóriában J] ! lemezen ! 
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A képhelyettes csak akkor hozza létre a képet, amikor a szövegszerkesztő Rajzol (Draw) 
műveletének meghívásával önmaga kirajzolására szólítja fel. A helyettes ezután közvetlenül 
a képhez továbbítja a kérelmeket, ezért hivatkoznia kell a képre, miután létrehozta. 


Tegyük fel, hogy a képek önálló fájlokban tárolódnak. Ebben az esetben a tényleges objek- 
tumra a fájlnévvel hivatkozhatunk. A helyettes emellett a kép kiterjedését (exten0), vagyis 
a szélességét és magasságát is tárolja. A kiterjedés tárolása lehetővé teszi a helyettes számá- 
ra, hogy kezelje a formázótól a méret beállítására vonatkozó kérelmeket, anélkül, hogy va- 
lóban példányosítaná a képet. 





Az alábbi osztálydiagram részletesebben illusztrálja a fenti példát: 


DokumentumSzerkesztő ] Grafika] 









































Rajzol() 
Szerezkiterjedésí) 
Tárolf) 
Betöltí) 
Kép kadszszetzásseszl KépHelyettes ifkép ss 0) ( G 
kép — BetöltképífájlNév]; 
" kép a 0-h----- need $ ; 

Rajzok) 1————— Rajzok) kép- Rajzolí) 

SzerezKiterjedésí) SzerezKiterjedésí) O- - - - - - 

Tárolt) Tárol) , 

Betöltő) Betöltí) : iflkép 50) ( Ma 

1 A retum kiterjedés 
 EZEEZZZENETE § else ( 
képMegvalósítás fájlNév retum kép-5 Szerezkiterjedésíj; 
kiterjedés kiterjedés ) 




















A dokumentumszerkesztő a beágyazott képeket az elvont Grafika (Graphic) osztály által 
meghatározott felületen keresztül éri el. Az igény szerint létrehozott képek osztálya a Kép- 
Helyettes (ImageProxy). A KépHelyettes a lemezen található képre a fájlnévvel hivatkozik. 
A fájlnevet argamentumként adjuk át a KépHelyettes konstruktorának. 


A KépHelyettes a kép befoglaló dobozát is tárolja, illetve egy hivatkozást a tényleges Kép 
(mage) példányra. A hivatkozás mindaddig nem érvényes, amíg a helyettes nem példá- 
nyosítja a képet. A Rajzol (Draw) művelet gondoskodik róla, hogy a kép példányosítására 
sor kerüljön, mielőtt a kérelmek továbbítódnának hozzá. A SzerezKiterjedés (GetExten0) 
csak akkor továbbít kérelmet a képnek, ha már létezik belőle példány, egyébként a Kép- 
Helyettes a tárolt kiterjedést adja vissza. 
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Alkalmazhatóság 


A Helyettes tervezési minta akkor használható, amikor egy egyszerű mutatónál rugalma- 
sabb vagy kifinomultabb hivatkozás szükséges egy objektumhoz. A mintát többek között 
a következő helyzetekben célszerű alkalmazni: 


had 


4. 


Távoli helyettes — helyi képviselőt biztosít egy másik címtérben található objektum 
számára. A NEXTSTEP [Add94] erre a célra az NXProxy osztályt használja. Coplien 
[Cop92] az ilyen helyettest , nagykövetnek" (Ambassador) nevezi. 

Virtuális helyettes — igény szerint létrehozza a költséges objektumokat. A Feladat részben 

leírt KépHelyettes is ilyen helyettes. 

Védelmi helyettes — szabályozza a hozzáférést az eredeti objektumhoz. A védelmi he- 

lyettesek akkor hasznosak, ha egyes objektumoknak különböző hozzáférési jogo- 

sultságokkal kell rendelkezniük. A Choices operációs rendszerben ICIRM93] találha- 
tó KernelProxy-k (RendszermagHelyettes-ek) például védett hozzáférést biztosíta- 
nak az operációs rendszer objektumai számára. 

Okos helyettes — olyan, mint egy sima mutató, csak az objektum elérésekor további 

műveleteket végez. Használatára néhány jellemző példa: 

— a tényleges objektumra való hivatkozások számlálása, hogy az objektum helye au- 
tomatikusan felszabadítható legyen, ha már nem hivatkozik rá semmi (okos mutató- 
nak is hívják [Ede92)); 

— egy maradandó objektum betöltése a memóriába az első rá vonatkozó hivatkozásnál; 

-— annak ellenőrzése, hogy hozzáférés előtt sor került-e a tényleges objektum zárolá- 
sára, amivel megakadályozható, hogy közben más objektum módosítsa. 


Szerkezet 








TénylegesAlany 


T.J 


Kérelmez() Cyládssálny éz Kérelmez(); 
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íme egy helyettes-szerkezet lehetséges objektumdiagramja futásidőben: 










egyÜgyfél 


alany 







egyHelyettes 


ténylegesAlany  €- 












egyTénylegesAlany 


Résztvevők 


e Helyettes (KépHelyettes) 

— Hivatkozást tart fenn, amelynek segítségével a helyettes elérheti a tényleges alanyt. 
A helyettes egy Alanyra (Subject) is hivatkozhat, ha a TénylegesAlany (RealSubjecD) 
és az Alany felülete azonos. 

— Az Alany felületével azonos felületet biztosít, hogy a helyettes kicserélhető legyen 
a tényleges alannyal. 

-— Szabályozza a hozzáférést a tényleges alanyhoz, és felelhet annak létrehozásáért 
és törléséért is. 

— Az egyéb felelősségek a helyettes típusától függnek: 

s A távoli helyettesek feladata a kérelmek és argumentumaik kódolása, illetve 
a kódolt kérelem elküldése a másik címtérben található tényleges alanynak. 

s A virtuális helyettesek ideiglenesen kiegészítő információkat tárolhatnak 
a tényleges alanyról, hogy elérését elhalaszthassák. A Feladat részben sze- 
replő KépHelyettes például a kép kiterjedését tárolja. 

, A védelmi helyettesek ellenőrzik, hogy a hívó rendelkezik-e a kérelem telje- 
sítéséhez szükséges hozzáférési engedéllyel. 

e Alany (Grafika) 

- Meghatározza a TénylegesAlany és a Helyettes (Proxy) közös felületét, hogy a He- 
lyettes mindazokon a helyeken használható legyen, ahol TénylegesAlanyra van 
szükség. 

s TénylegesAlany (Kép) 
— Meghatározza a helyettes által képviselt tényleges objektumot. 


Együttműködés 


e A Helyettes szükség esetén kérelmeket továbbít a TénylegesAlanynak, a helyettes tí- 
pusától függően. 
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Következmények 


A Helyettes minta közvetettséget biztosít az objektumok elérésében. Ennek a közvetettség- 
nek a helyettes típusától függően számos előnye van: 


1. A távoli helyettes elrejti, hogy az objektum egy másik címtérben található. 
A virtuális helyettes optimalizálja a viselkedést, például azzal, hogy igény szerint 
hozza létre az objektumokat. 

3. A védelmi és okos helyettesek további műveleteket tesznek lehetővé az objektumok 
elérésekor. 


A Helyettes mintával emellett még valamit elrejthetünk az ügyfelek elől, mégpedig a , máso- 
lás íráskor" (copy-on-write) megoldást, ami az igény szerinti létrehozáshoz kapcsolódik. 
A nagy és bonyolult objektumok másolása költséges művelet lehet, pedig e költség szük- 
ségtelen, ha a másolat soha nem módosul. Ha helyettes használatával elhalasztjuk a máso- 
lást, gondoskodhatunk róla, hogy a másolás költségét csak akkor fizetjük meg, ha az objek- 
tumot módosítjuk. 





Ahhoz, hogy a másolás íráskor működjön, az alanyra vonatkozó hivatkozások számlálására 
van szükség. A helyettes másolása csupán a hivatkozásszámláló értékét növeli. Az alany 
tényleges másolását csak akkor hajtja végre a helyettes, ha az ügyfél olyan műveletet kérel- 
mez, ami módosítja azt. Ekkor a helyettesnek csökkentenie is kell a hivatkozásszámláló ér- 
tékét. Amikor az érték nullára csökken, az alany törlődik. 








A másolás íráskor jelentősen csökkenti a nehézsúlyú alanyok másolásának költségét. 


Megvalósítás 


A Helyettes minta révén a következő nyelvi szolgáltatások aknázhatók ki: 


1. A Ctt tagelérő műveletének túlterhelése. A C--4 támogatja a tagok elérésére szolgáló 
operator-35 művelet túlterhelését. E megoldás révén további műveleteket végez- 
hetünk, amikor egy objektum hivatkozását feloldjuk (dereferencia), ez pedig segít 
günkre lehet egyes helyettestípusok megvalósításában; a helyettes ugyanúgy visel- 
kedik, mint egy mutató. 





A következő példa azt mutatja be, hogyan használható a fenti eljárás egy ImagePtr 
(KépMutató) nevű virtuális helyettes megvalósítására. 
class Image; 
extern Image LoadAnlmageFile(const char"); 
77 külső függvény 


class ImagePtr ( 
public: 
ImagePtr(const chart imageFile); 


virtual "7ImagePtr(); 
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virtual Imaget operator—5(); 
virtual Images operator" (); 
private: 
Imagetr Loadimage( ) ; 
private: 
Imager . image; 
const char:  imageFile; 


ImagePtr : : ImagePtr (const char?" thelmageFile) ( 
.-imageFile - thelmageFile; 
.-image - 0; 


Imagetr ImagepPtr::LoadImage () ( 
if ( image -- 0) ( 
image - LoadAnlmageFile( imageFile) ; 
? 
return . image; 


) 


A túlterhelt -—- és " műveletek (operátorok) a LoadImage (Betöltkép) segítségével 
adják vissza az image-et a hívóknak Cilletve töltik be, ha szükséges). 
Imaget ImagepPtr::operator-5 () ( 
return LoadImage ( ) ; 


ji 


Imageg ImagePtr::operatort () ( 
return $"LoadImage[( ) ; 


1) 


E megközelítés révén anélkül hívhatjuk meg az Image műveleteit ImagePtr objektu- 
mokon keresztül, hogy a műveleteket az TmagePtr felület részévé kellene tennünk: 


ImagePtr image - ImagePtr("egyKépFájlNév") ; 
image-sDraw(Point(50, 100)); 
7/ (image.operator-5())-sDraw(Point(50, 100)) 


Megfigyelhetjük, hogy az image helyettes mutatóként viselkedik, pedig nem egy 
Image-re hivatkozó mutatóként vezetjük be. Ebből következően nem használható 
pontosan úgy, mint egy valódi Image mutató, vagyis az ügyfeleknek különbözőkép- 
pen kell kezelniük az Image és InagePtr objektumokat. 

A tagelérő művelet túlterhelése nem felel meg mindenféle helyettesnél. Egyes he- 
lyetteseknek pontosan tudniuk kell, melyik művelet hívására került sor, így az ilyen 
túlterhelés ebben az esetben nem működik. 
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Vegyük a Feladat részben szereplő virtuális helyettes példáját. A képet egy adott idő- 
pontban (a Draw művelet meghívásakor), és nem a képre való minden hivatkozás- 
nál kell betölteni. A tagelérő művelet túlterhelése ezt a megkülönböztetést nem teszi 
lehetővé. Tehát itt egyenként, magunknak kell megvalósítanunk a helyettes minden 
olyan műveletét, ami kérelmet továbbít az alanynak. 

Az említett műveletek általában nagyon hasonlítanak egymásra, amint azt majd 
a Példakód részben is láthatjuk. Jellemzően mindegyik művelet ellenőrzi, hogy a ké- 
relem érvényes-e, hogy az eredeti objektum létezik-e, és így tovább, mielőtt a kérel- 
met az alanyhoz továbbítaná. Ezt a kódot újra és újra megírni meglehetősen fárasztó, 
ezért többnyire előfeldolgozó segítségével automatikusan állítják elő. 


. A docsNotUnderstand használata a Smalltalk-ban. A Smalltalk egy horgot biztosít, 


amellyel támogathatjuk a kérelmek automatikus továbbítását. Amikor egy ügyfél 
üzenetet küld egy olyan fogadónak, amelynek nincs megfelelő metódusa, a nyelv- 
ben a doesNotUndestand: aMessage hívására kerül sor. A Helyettes (Proxy) osz- 
tály úgy írhatja felül a doesNotUnderstand-et, hogy az üzenet továbbítódjon az 
alanyhoz. 

Ahhoz, hogy biztosítsuk, a kérelem továbbítódik az alanyhoz, nem pedig csendesen 
elnyeli a helyettes, meghatározhatunk egy olyan Helyettes osztályt, amely egyetlen 
üzenetet sem ért meg. A Smalltalk ezt úgy támogatja, hogy a Helyettest ősosztály nél- 
küli osztályként határozza meg." 

A doesNotUnderstana: legnagyobb hátránya az, hogy a legtöbb Smalltalk rend- 
szer néhány olyan különleges üzenettel rendelkezik, amelyeket közvetlenül a virtuá- 
is gép kezel, így nem kerül sor a szokásos metódus-kikeresésre. Az egyetlen, ame- 
yet általában Object-ben valósítanak meg Cés így érintheti a helyetteseke?) az azo- 
nosságvizsgáló -- művelet. 

Ha a helyettes megvalósítására a doesNotunderstand:-et használjuk, meg kell 
kerülnünk ezt a problémát, hiszen a helyettesek azonossága nem jelenti a tényleges 
alanyok azonosságát. Emellett az is hátrány, hogy a doesNotUnderstand : -et hiba- 
kezelésre tervezték, nem helyettesek építésére, ezért általában elég lassú. 





. A helyettesnek nem mindig kell ismernie a tényleges alany típusát. Ha egy Helyettes 


osztály kizárólag egy elvont felületen keresztül léphet kapcsolatba az alannyal, nincs 
szükség rá, hogy minden TénylegesAlany osztályhoz külön Helyettes osztályt készít- 
sünk — a helyettes minden TénylegesAlany osztályt egységesen kezelhet. Ha azon- 
ban a Helyettesek példányosítják a TénylegesAlanyokat (mint ahogy a virtuális he- 
lyettesek teszik), ismerniük kell a konkrét osztályt. 





6 


A NEXTSTEP [Add941 elosztott objektumainak megvalósítása (pontosabban az NXProxy osztály) is ezt a megol- 
dást alkalmazza. Itt a forward (továbbíg felülírására kerül sor, ami a NEXTSTEP hasonló célú horga. 
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A megvalósítással kapcsolatban szót kell ejtenünk arról is, hogyan hivatkozhatunk az alany- 
ra annak példányosítása előtt. Egyes helyetteseknek attól függetlenül kell hivatkozniuk 
a hozzájuk tartozó alanyra, hogy az a memóriában vagy a lemezen található-e, vagyis vala- 
milyen címtérfüggetlen objektumazonosítót kell használniuk. A Feladat részben erre a célra 
a fájlnevet alkalmaztuk. 


Példakód 


A következő kódban kétféle helyettest valósítunk meg: a Feladat részben leírt virtuális he- 
lyettest, és egy olyan helyettest, ami a doesNotUnderstand: horgot használja." 


1. Virtuális helyettes. A Graphic (Grafika) osztály határozza meg a grafikus osztályok 
felületét: 
class Graphic ( 
public: 


virtual "Graphic(); 


virtual void Draw(const Pointg at) - 0; 
virtual void HandleMouse(Eventg event) - 0; 


virtual const Pointg GetExtent() Úgy 


virtual void Load(istreamg from) - 

virtual void Save(ostreamg to) - 0; 
protected: 

Graphic(); 


0; 


1; 


Az Image (Kép) osztály a képfájlok megjelenítéséhez valósítja meg a Graphic felü- 
letet. Az Image felülbírálja a HanáleMouse (KezelEgér) műveletet, hogy a felhasz- 
nálók interaktívan átméretezhessék a képet. 
class Image : public Graphic ( 
public: 
Image(const char! file); //képet tölt be egy fájlból 
virtual "Image ( ) ; 


virtual void Draw(const Pointfő at); 
virtual void HandleMouse(Eventg event); 


virtual const Pointg GetExtent ( ) ; 


virtual void Load(istream6 from); 
virtual void Save(ostreamg to); 
private: 
TUsés 
1; 





7 A Bejáró mintánál a következő fejezetben egy másfajta helyettest is bemutatunk. 
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Az ImageProxy (KépHelyettes) felülete megegyezik az Image-ével: 


class ImageProxy : public Graphic ( 
public: 
ImageProxy(const char: imageFile); 
virtual "ImageProxy ( ) ; 


virtual void Draw(const Pointő at); 
virtual void HandleMouse(Eventé event); 


virtual const Pointg GetExtent(); 


virtual void Load(istreams from); 
virtual void Save(ostreamg to); 
protected: 
ImageY GetImage() ; 
private: 
Imagetr image; 
Point . extent; 
charty  fileName; 
l; 


A konstruktor helyi másolatot ment a képet tároló fájl nevéről, és kezdőértéket ad az 
-extent ( kiterjedés) és image ( kép) tagoknak: 
ImageProxy : : InageProxy (const char?" fileName) ( 
.-fileName - strdup(fileName) ; 
-extent - Point::Zero; //a kiterjedést még nem ismerjük 
-image - 0; 


Imaget ImageProxy::GetImage() ( 
if ( image -- 0) ( 
.-image - new Image(fileName) ; 
) 
return . image; 
) 
A GetExtent (SzerezkKiterjedés) megvalósítása, ha lehetséges, az ideiglenesen tá- 
rolt kiterjedést adja vissza, egyébként a kép betöltődik a fájlból. A Draw (Rajzol) tölti 
be a képet, a HandleMouse pedig a tényleges képhez továbbítja az eseményt. 
const Pointg ImageProxy::GetExtent () ( 
if ( extent -- Poóint::Zero) ( 
.extent - GetImage()-5GetExtent ( ) ; 
 j 


return extent; 


1. 


void ImageProxy::Draw (const Pointe at) ( 
GetImage ( ) sDraw(at ) ; 
) 
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void ImageProxy::HandleMouse (Eventső event) í( 
GetImage ( ) -HandleMouse (event ) ; 
gr 
A Save (Men0 művelet egy folyamba menti a tárolt képkiterjedést és fájlnevet. 
A Load (Betöl0 elkéri ezeket a információkat, és előkészíti a megfelelő tagokat. 
void ImageProxy::Save (ostreamg to) ( 
to cc extent cc  fileName; 


y 


void ImageProxy::Load (istreamg from) ( 
from 55 extent 55  fileName; 


1. 


Végül, tegyük fel, hogy van egy TextDocument (SzövegDokumentum) nevű osztá- 
lyunk, amely tartalmazhat Graphic objektumokat: 
class TextDocument ( 
public: 
TextDocument ( ) ; 


void Insert((Graphic") ; 
HA ess 
hi; 


Egy ImageProxy-t így szúrhatunk be egy szövegdokumentumba: 


TextDocumentt text - new TextDocument; 
Vas é 
text-5sInsert (new ImageProxy ( "egyKépFájlNév" ) ) ; 


2. Helyettesek, amelyek a doesNotUnderstand-et használják. A Smalltalkban olyan osz- 
tályok meghatározásával készíthetünk általános helyetteseket, amelyek ősosztálya 
a nil", valamint a docsNotUnderstand: metódus meghatározásával képes az üze- 
netek kezelésére. 

Az alábbi metódus feltételezi, hogy a helyettesnek van egy realSubject metódu- 
sa, ami a tényleges alanyt adja vissza. Az InageProxy esetében ez a metódus ellen- 
őrizné, hogy létrejött-e az Image, szükség esetén létrehozná, és végül visszaadná. 
A metódus a perform: withArgument s : segítségével juttatja célba az üzenetet. 
doöesNotUnderstand: aMessage 
" self realSubject 

perform: aMessage selector 

withArguments: aMessage arguments 
A doesNotUnderstand: argumentuma a Message (Üzenet) egy példánya, ami 
a helyettes által nem értelmezhető üzenetet jelképezi. Így a helyettes minden üzenetre 
úgy válaszol, hogy ellenőrzi, létezik-e az alany, mielőtt az üzenetet továbbítaná hozzá. 





5 Szinte minden osztály végső ősosztálya az Object, ezért a kifejezés egyenértékű azzal, mintha azt mondanánk: 
olyan osztályok meghatározásával, amelyeknek az Object nem őse". 
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A doesNotUnderstand: egyik előnye, hogy különféle feldolgozó műveleteket vé- 
gezhet. Például egy védelmi helyettest hozhatunk létre, ha meghatározzuk az elfo- 
gadható üzenetek halmazát (1legalMessages), majd az alábbi metódussal látjuk el 
a helyettest: 
docsNotUnderstand: aMessage 
"  (legalMessages includes: aMessage selector) 
ifTrue: [self realSubject 
perform: aMessage selector 
withArguments: aMessage arguments 
ifFalse: (self error: "Érvénytelen művelet!"] 


A metódus ellenőrzi, hogy az üzenet érvényes-e, mielőtt továbbítaná azt a tényleges 
alanyhoz. Ha az üzenet nem elfogadható, error : üzenetet küld a helyettesnek, ami 
a hibák végtelen ciklusát indíthatja el, hacsak a helyettes meg nem határozza az 
error:-t. Az error: meghatározását az esetleges metódusokkal együtt az Object 
osztályból kell ide másolni. 


Ismert felhasználások 


A Feladat részben szereplő virtuális helyettes az ET-- szövegépítő-blokk osztályaiból 
származik. 


A NEXTSTEP IAdd94] a megosztható objektumok helyi képviselőiként használ helyetteseket 
(az NXProxy osztály példányai. A kiszolgálók helyetteseket hoznak létre a távoli objektu- 
mok számára, amikor az ügyfelek igénylik azokat. Amikor üzenet érkezik, a helyettes argu- 
mentumaival együtt kódolja, majd a kódolt üzenetet továbbítja a távoli alanyhoz. Az alany 
ugyanígy kódolja az esetleges eredményeket, és visszaküldi az NXProxy objektumnak. 


McCullogh IMcC87] a távoli objektumok helyettesekkel való elérését tárgyalja a Smalltalk- 
ban. Pascoe [Pas86] azt írja le, hogyan adhatunk , mellékhatásokat" a metódushívásokhoz 
és a hozzáférés-szabályozáshoz úgynevezett , egységbe zárókkal" (Encapsulator). 


Kapcsolódó minták 


Illesztő: Az illesztők más felületet biztosítanak az illesztett objektumok számára, míg a he- 
lyettesek felülete ugyanaz, mint alanyaiké. Mindazonáltal az elérés védelmére használt he- 
lyettesek visszautasíthatnak egy olyan műveletet, amit az alany végrehajtana, így felületük 
az alany felületének részhalmaza is lehet. 


Díszítő: Bár a díszítők megvalósítása hasonló lehet a helyettesekéhez, a díszítők célja más. 
A díszítők új felelősségeket adnak egy objektumhoz, míg a helyettesek az objektumhoz va- 
ló hozzáférést szabályozzák. 
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A helyettesek megvalósításának hasonlósága a díszítőkéhez különböző lehet. Egy védelmi 
helyettes pontosan ugyanúgy is megvalósítható, mint egy díszítő, míg egy távoli helyettes 
nem hivatkozik közvetlenül az alanyára, csak olyan közvetett hivatkozásokon keresztül, 
mint amilyen a számítógép azonosítója és a célgépen érvényes helyi cím. A virtuális helyet- 
tesek kezdetben a fájlnévhez hasonló közvetlen hivatkozásokat alkalmaznak, de végül egy 
közvetett hivatkozást szereznek meg és használnak. 


A szerkezeti mintákról 


Olvasás közben bizonyára észrevettük a hasonlóságokat a szerkezeti minták között, külö- 
nösen résztvevőiket és azok együttműködését illetően. A hasonlóságok valószínűleg abból 
erednek, hogy mindegyik minta a kód és az objektumok szervezésére szolgáló nyelvi szol- 
gáltatások azonos részhalmazára támaszkodik: az osztály alapú minták esetében egyszeres 
és többszörös öröklést, az objektummintáknál objektum-összetételt használunk. A hasonló- 
ságok azonban elfedik az egyes minták céljai közti különbségeket, ezért ebben a részben 
összehasonlítjuk a szerkezeti minták egyes csoportjait, hogy előnyeikről tisztább képet 
kapjunk. 


Illesztő vagy Híd? 


Az Illesztő és a Híd minta osztozik néhány közös tulajdonságon: mindkettő a rugalmassá- 
got támogatja azáltal, hogy közvetett elérést nyújt egy objektumhoz, illetve mindkettőben 
szerepel az objektumétól eltérő felületen keresztüli kérelemtovábbítás. 


A két minta közti legfontosabb különbséget céljuk jelenti. Az Illesztő minta két meglevő, el- 
térő felület összeegyeztetésére összpontosít. A felületek megvalósításával, vagy egymástól 
független fejlesztésével nem foglalkozik, vagyis arra szolgál, hogy két önállóan tervezett osz- 
tály együttműködését biztosítsa, anélkül, hogy bármelyik megvalósítását át kellene dolgoz- 
nunk. A Híd minta ezzel szemben egy elvont fogalmat és annak (esetleg számos) megvalósí- 
tását köti össze. A megvalósító osztályok cserélgethetők, mégis stabil felületet nyújt az ügy- 
feleknek, ezenkívül könnyen adhatók hozzá új megvalósítások a rendszer fejlesztése során. 


Az említett különbségek eredményeképpen az Illesztő és a Híd mintát gyakran a szoftver 
életciklusának különböző pontjain alkalmazzák. Az illesztőkre általában akkor mutatkozik 
igény, amikor felfedezzük, hogy két össze nem egyeztethető osztálynak együtt kellene mű- 
ködnie (általában a kód megkettőzésének elkerülése végett), és ez a csatolás előre nem lát- 
ható. A hidak alkalmazásánál viszont előre tudjuk, hogy az adott elvont fogalomnak szá- 
mos megvalósítása kell legyen, és a kettőnek egymástól függetlenül fejleszthetőnek kell 
lennie. Az Illesztő minta tervezés után biztosítja az együttműködést, míg a Híd minta a ter- 
vezés előtt. Ez nem jelenti azt, hogy az Illesztő alacsonyabb rendű a Hídnál, csupán azt mu- 
tatja, hogy céljuk különböző. 
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A homlokzatokra (lásd a Homlokzat mintái) gondolhatunk úgy is, mint objektumok halma- 
zának illesztőire, de ez az értelmezés figyelmen kívül hagyja azt a tényt, hogy a homlokza- 
tok új felületet határoznak meg, míg az illesztők egy régi felület újrahasznosításával mű- 
ködnek. Véssük jól észbe, hogy az illesztők mindig két létező felület együttműködését biz- 
tosítják, nem pedig újat hoznak létre. 


Összetétel, Díszítő vagy Helyettes? 


Az Összetétel és a Díszítő minta szerkezeti diagramja hasonló, ami azt tükrözi, hogy mind- 
kettő önhívó összetételre épül, és így rendez el korlátlan számú objektumot. Ez a hasonló- 
ság azt sugallhatja számunkra, hogy egy díszítő objektum nem más, mint egy csökevényes 
összetétel, de ennek semmi köze a Díszítő minta lényegéhez. A hasonlóság valójában meg- 
áll az önhívó összetételnél — a két minta célja ismét csak egészen más. 


A Díszítőt arra tervezték, hogy alosztályok származtatása nélkül adhassunk felelősségeket 
objektumokhoz. Így elkerülhető az alosztályok számának robbanásszerű növekedése, ami 
bekövetkezne, ha statikusan próbálnánk a felelősségek minden lehetséges kombinációját 
lefedni. Az Összetétel minta más célt szolgál: az osztályok szervezésére összpontosít, hogy 
rokon objektumokat egységesen, illetve több objektumot egyként kezelhessünk. Közép- 
pontjában tehát nem a díszítés, hanem az ábrázolás áll. 


Az említett célok különböznek, de kiegészítik egymást, amiből az is következik, hogy a két 
mintát gyakran együtt használják. Mindkettő olyan felépítést eredményez, melynek révén 
egyszerűen objektumok egymáshoz csatlakoztatásával, új osztályok meghatározása nélkül 
építhetünk programokat. Lesz egy elvont osztályunk, amelynek egyes alosztályai összetéte- 
lek, míg mások díszítők lesznek, más alosztályok pedig a rendszer alapvető építőköveit va- 
lósítják meg. Ebben az esetben a díszítők és összetételek közös felületet kapnak. A Díszítő 
minta szempontjából az összetételek a KonkrétElem szerepét töltik be, míg az Összetétel 
minta felől tekintve a díszítők Levelek. A két mintát természetesen nem muszáj együtt al- 
kalmazni, céljuk pedig — mint láttuk — teljesen különböző. 


Egy másik tervezési minta, amelynek szerkezete hasonló a Díszítőéhez, a Helyettes. Mind- 
két minta azt írja le, hogyan biztosíthatunk közvetett elérést egy objektumhoz, és mind 
a helyettes, mind a díszítő objektum megvalósítása egy másik objektumra hivatkozik, 
amelyhez kérelmeket továbbítanak. A cél azonban ebben az esetben is különböző. 


A Díszítőhöz hasonlóan a Helyettes minta is összeállít egy objektumot, és azonos felületet 
nyújt az ügyfeleknek. Abban viszont már különbözik, hogy nem foglalkozik a tulajdonsá- 
gok dinamikus csatolásával és leválasztásával, és nem is önhívó összetételre tervezték. Cél- 
ja egy helyettes biztosítása egy alany számára, amikor annak közvetlen elérése nemkívána- 
tos vagy kényelmetlen, például mert egy távoli gépen található, elérése engedélyhez kötött, 
vagy maradandó (perzisztens) objektum. 
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A Helyettes minta kulcsa az alany, amelyhez a helyettes elérést biztosít, vagy megtagadja 
azt. A Díszítő mintában az elemek csak a szolgáltatások egy részét nyújtják, a többiről a dí- 
szítők gondoskodnak. A Díszítő minta használatára akkor kerülhet sor, amikor egy objek- 
tum teljes szolgáltatásköre nem határozható meg fordításkor, vagy legalábbis nem egysze- 
rűen. Ez a meghatározatlanság teszi az önhívó összetételt a Díszítő minta lényegi elemévé. 
Ez a Helyettes minta esetében nem áll fenn, mert itt a középpontban egyetlen kapcsolat — 
a helyettes és alanya kapcsolata — áll, ami statikusan is kifejezhető. 


Az említett különbségek jelentősek, mert mindegyik az objektumközpontú rendszerek egy- 
egy visszatérő problémájára ad megoldást. Ez azonban nem jelenti azt, hogy ezek a terve- 
zési minták nem használhatók együtt. Elképzelhető például egy olyan , helyettesdíszítő" , 
ami egy helyettest egészít ki új feladatokkal, illetve egy olyan , díszítőhelyettes", ami egy tá- 
voli objektumot díszít. Az ilyen keverékek haszna elképzelhető (bár gyakorlati példát most 
egyet sem tudnánk felhozni), de ami biztos, hogy felbonthatók valóban hasznos mintákra. 





Viselkedési minták 


A viselkedési minták közzépontjában az algoritmusok állnak, illetve a felelősségi körök 
hozzárendelése az objektumokhoz. E minták nem csupán osztályok vagy objektumok 
rendszerét írják le, hanem a közöttük folyó kommunikációt is, így a futásidőben nehezen 
nyomon követhető, bonyolult vezérlési folyamatot modellezik, mégpedig úgy, hogy éppen 
a vezérlésről terelik el a figyelmünket, hogy az objektumok között fennálló kapcsolatokra 
összpontosíthassunk. 


A viselkedési osztályminták a kívánt viselkedést öröklés segítségével rendelik az egyes osz- 
tályokhoz. Ez a fejezet két ilyen mintát tartalmaz, közülük a Sablonfüggvény (Template 
Method) az egyszerűbb és az ismertebb. E módszer egy algoritmus elvont meghatározására 
szolgál, amit lépésről lépésre ír le. Minden egyes lépés egy elvont műveletet vagy egy alap- 
műveletet indít el. Az algoritmust az alosztályok töltik meg tartalommal, amikor meghatá- 
rozzák az elvont műveleteket. A másik itt bemutatandó viselkedési osztályminta az Értel- 
mező (Interpreter), amely egy osztályhierarchia formájában ír le egy nyelvtant, amelyhez 
egy értelmezőt valósít meg, az osztályok példányaival dolgozó műveletként. 


A viselkedési objektumminták öröklés helyett objektum-összetételt alkalmaznak. Egyes 
minták azt írják le, hogyan működik együtt társobjektumok egy csoportja, hogy végrehajt- 
hassanak egy olyan műveletet, amit egyetlen objektum önmagában nem lenne képes vég- 
rehajtani. Itt az a lényeges kérdés, hogyan értesülnek egymásról az objektumok. Hivatkoz- 
hatnának kifejezetten is egymásra, de ekkor csatolásuk mértéke nemkívánatos módon 
megnövekedne; szélsőséges esetben minden objektum ismerne minden objektumot. 
A Közvetítő (Mediator) minta ezt úgy kerüli el, hogy a társobjektumok közé egy közvetítő 
objektumot iktat be, amely biztosítja a laza csatoláshoz szükséges közvetettséget. 





A Felelősséglánc (Chain of Responsibility) minta még ennél is lazább csatolást hoz létre, az- 
által, hogy megengedi, hogy egy objektumnak jelölt objektumok láncán keresztül rejtve 
küldjünk kérelmet. A kérelmet a futásidejű körülményektől függően bármelyik jelölt telje- 
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sítheti. A jelöltek száma nem korlátos, és azt is megválaszthatjuk, mely jelöltek vegyenek 
részt futásidőben a felelősségláncban. 


A Megfigyelő (Observer) minta objektumok közötti függőségeket határoz meg és tart fenn. 
A Megfigyelő klasszikus példája a Smalltalk modell-nézet-vezérlő (Model/View/Controller) 
felosztása, amelyben a modell minden nézete értesítést kap, ha a modell állapota megváltozik. 


Más viselkedési objektumminták alapja a viselkedések objektumba zárása, illetve a kérel- 
mek teljesítésének ezen objektumokra való átruházása. A Stratégia (Strategy) minta egy al- 
goritmust tokoz be egy objektumba, megkönnyítve ezáltal az algoritmus meghatározását és 
megváltoztatását. A Parancs (Command) minta egy kérelmet zár egy objektumba, hogy az 
paraméterként átadható, előzménylistában tárolható, vagy más módon kezelhető legyen. 
Az Állapot (State) minta egy objektum állapotaiból hoz létre önálló objektumot, így az ob- 
jektum módosíthatja viselkedését, amikor állapotobjektuma megváltozik. A Látogató (Visi- 
tor) minta az olyan viselkedéseket zárja egységbe, amelyek másképp több osztályban len- 
nének elosztva, a Bejáró (Iterator) pedig az összesítő (aggregá0) objektumok elemeinek el- 
érésére és bejárására ad elvont leírást. 


Felelősséglánc 


Viselkedési objektumminta 


Egyéb nevek 

Chain of Responsibility, Válaszlánc 

Cél 

A minta arra szolgál, hogy elkerüljük a kérelem küldőjének a fogadóhoz való kötését. Ezt 
úgy érjük el, hogy több objektumnak is jogot adunk a kérelem kezelésére. A fogadó objek- 


tumokat láncba állítjuk, amelyen a kérelem addig halad, amíg el nem ér egy objektumot, 
ami képes a kezelésére. 


Feladat 


Adott egy grafikus felhasználói felület; ehhez szeretnénk környezetfüggő súgót készíteni, 
vagyis azt elérni, hogy ha a felhasználó a felület valamelyik elemére kattint, az adott elem- 
hez segítséget kaphasson. A megjelenő súgószöveg a választott felületi elemtől és annak 
környezetétől függ, például egy párbeszédablak egy gombjához más információ tartozhat, 
mint a főablak egy ugyanolyan gombjához. Ha az adott elemhez nem tartozik súgószöveg, 
a súgórendszernek az elem környezetéről (például a párbeszédablakról, mint egészről) kell 
valamilyen általánosabb információt megjelenítenie. 


Felelősséglánc 
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Természetesen adódik, hogy az információkat az általánosság foka szerint rendezzük, 
a legkonkrétabbtól a legáltalánosabbig. Az is világos, hogy a súgó megjelenítésére irányuló 
kérelmet több felhasználói felületi objektum is kezelheti; az, hogy az adott pillanatban me- 
lyik, a környezettől és az elérhető információ konkrétságától függ. 


A gond az, hogy az információt ténylegesen szolgáltató objektumot a kérelmet kibocsátó 
objektum (például a gomb) nem feltétlenül ismeri. Vagyis egy olyan módszerre van szük- 
ség, amellyel a kérelmező objektumot függetleníthetjük az információ szolgáltatására képes 
objektumoktól. A Felelősséglánc minta ezt a módszert határozza meg. 


Az alapgondolat az, hogy a küldőt és a fogadót azáltal választjuk szét, hogy több objektum- 
nak is lehetőséget adunk a kérelem teljesítésére. A kérelem végighalad ezen objektumok lán- 
cán, amíg egy olyanhoz nem ér, amelyik ténylegesen végrehajtja. 













egyNNyomtatásGomb 


egyOKGomb 









konkrét általános 


A lánc első objektuma megkapja a kérelmet és vagy teljesíti, vagy továbbítja a lánc követke- 
ző jelöltjének, amely hasonlóképpen cselekszik. A kérelmező objektum nem tudja, melyik 
objektum fogja kezelni a kérést, ezért azt mondjuk, a kérelem rejtett fogadóval (implicit 
receiver) rendelkezik. 


Tegyük fel, hogy a felhasználó kattintással egy Nyomtatás (Print) feliratú gombhoz kér segít- 
séget. A gombot egy NyomtatásPárbeszédablak (PrintDialog) példány tartalmazza, amely is- 
meri az őt tartalmazó alkalmazásobjektumot (ásd az előző ábrát). Az alábbi együttműködési 
diagram azt mutatja, hogyan továbbítódik a kérelem a felelősségláncon keresztül: 
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egyNNyomtatásGomb  egyNNyomtatásPárbeszédablak egyAlkalmazás 







KezelSúgói) 


KezelSúgó() 





Ebben az esetben sem az egyNyomtatásGomb (aPrintButton), sem az egyNyomtatásPárbe- 
szédablak (aPrintDialog) nem kezeli a kérelmet; az az egyAlkalmazás (anApplication) ob- 
jektumnál áll meg, amely vagy válaszol rá, vagy figyelmen kívül hagyja. A kérelmet kibo- 
csátó ügyfél nem hivatkozik közvetlenül a végrehajtó objektumra. 





Ahhoz, hogy biztosíthassuk a fogadók rejtettségét és továbbíthassuk a kérelmet a láncon át, 
a lánc objektumai közös felülettel rendelkeznek, ami a kérelmek kezelését és a lánc követ- 
kező elemének (követő, successor) elérését írja le. A súgórendszer például meghatározhat 
egy Súgókezelő (HelpHandler) nevű osztályt, a megfelelő KezelSúgó (HandleHelp) műve- 
lettel együtt. A SúgóKezelő lehet a jelölt objektumosztályok szülőosztálya, de meghatároz- 
ható mixin ( bekeveredő") osztályként is. Ekkor a súgókérelmeket kezelni kívánó osztá- 
lyok szülővé tehetik a SúgóKezelőt: 








Alkalmazás 











if képes kezel ( 
w Párheszádablak ] Gomb roles 
hb else ( 
KezelSúgó() Kezelő::KezelSúgó() 
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A Gomb (Button), Párbeszédablak (Dialog) és Alkalmazás (Application) osztályok a súgó- 
kérelmeket a SúgókKezelő (HelpHandler) műveleteinek segítségével teljesítik. A Kezelsúgó 
(HandleHelp) művelet alapértelmezés szerint a kérelmet a következő jelölthöz továbbítja; 
az alosztályok e művelet felülbírálásával jeleníthetnek meg súgót megfelelő környezet ese- 
tén, más esetben pedig az alapértelmezett megvalósítás szerint továbbítják a kérelmet. 


Alkalmazhatóság 


A Felelősséglánc minta a következő esetekben alkalmazható: 


e Egy kérelmet egynél több objektum kezelhet, a kezelő pedig előre nem ismert, azt 
automatikusan kell kijelölni. 

s Anélkül szeretnénk kérelmet intézni több objektum valamelyikéhez, hogy konkré- 
tan meghatároznánk a fogadót. 

e A kérelem teljesítésére képes objektumok halmazát dinamikusan kell meghatározni. 


Szerkezet 






KonkrétkKezelő1 KonkrétKezelő2 






Kezelkérelem() 


Az objektumszerkezet valahogy így festhet: 


egyÜgyfél gyk f- 
egyKonkrétkezeli 


követő e 


egykKezelő €- 











egyKonkrétkKezelő 
követő 
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Résztvevők 


s Kezelő SúgóKezelő) 
— Felületet határoz meg a kérelmek kezeléséhez. 
— Megvalósítja a következő jelölthöz való kapcsolódást. (Nem kötelező.) 
e  KonkrétKezelő (NyomtatásGomb, NyomtatásPárbeszédablak) 
— Kezeli a felelősségi körébe tartozó kérelmeket. 
— Képes elérni a következő jelöltet. 
— Ha a Konkrétkezelő (ConcreteHandler) képes teljesíteni a kérelmet, akkor teljesí- 
ti, egyébként pedig továbbítja a rákövetkező jelöltnek. 
e Ügyfél 
— Kérelmet intéz a lánc egy KonkrétkKezelő objektumához. 


Együttműködés 


2 Amikor az ügyfél kérelmet bocsát ki, a kérelem végighalad a láncon, amíg egy Konk- 


rétkezelő objektum felelősséget nem vállal a kezeléséért. 


Következmények 


A Felelősséglánc minta előnyei és hátrányai a következők: 


1. Lazább csatolás. A minta szükségtelenné teszi, hogy a hívók tudják, melyik objek- 
tum milyen kérelmeket kezel, csak azt kell tudniuk, hogy a kérelem kezelése ,meg- 
elelően" meg fog történni. Sem a küldő, sem a fogadó nem tud egymásról; a lánc 
objektumainak a lánc szerkezetét sem kell ismerniük. 
Mindezek eredményekért a Felelősséglánc egyszerűsíti az objektumok közötti kap- 
csolatokat: az objektumok nem hivatkoznak minden fogadójelöltre, csak a rájuk 
övetkezőre. 
2. Nagyobb rugalmasság az objektumok felelősségi körének kijelölésében. A Felelősség- 
ánc minta nagyobb szabadságot ad az objektumok feladatainak kiosztásában: egy- 
egy kérelem kezeléséhez futásidőben is kiegészíthetjük vagy más módon módosít- 
natjuk a láncot, de ezt párosíthatjuk azzal is, hogy bizonyos kérelmek teljesítésére 
szakosodott alosztályokat hozunk létre statikusan. 
3. A kérelem teljesítése nem garantált. Miután a kérelmeknek nincs konkrét fogadójuk, 
kezelésükre nincs semmilyen garancia — a kérelem végighaladhat a láncon, anélkül, 
1ogy egyetlen objektum is válaszolna rá. Ez akkor is megtörténhet, ha a lánc beállítá- 
sa nem megfelelő. 
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Megvalósítás 


A Felelősséglánc minta megvalósításával kapcsolatban a következő dolgok lényegesek: 


1 


A hivatkozási lánc megvalósítása. A lánc kétféleképpen hozható létre: 
(a) Új hivatkozások meghatározásával. (Ez általában a Kezelőben történik, de 
a Konkrétkezelők is megtehetik.) 
(b) A meglevő hivatkozások felhasználásával. 
Az eddigi példákban új hivatkozásokat alkalmaztunk, de a hivatkozási lánc létreho- 
zásához sok esetben használhatjuk a meglevő objektumhivatkozásokat is. Ilyenek 
lehetnek például a rész-egész hierarchiák szülőhivatkozásai; a grafikus felületi ele- 
mek általában tartalmaznak ilyeneket. Az Összetétel minta ismertetésénél részlete- 
sebben is kitérünk a szülőhivatkozásokra. 
A meglevő hivatkozások használata akkor célszerű, ha illeszkednek a létrehozandó 
lánchoz. Amennyiben megfelelnek, megkímélnek minket attól, hogy újakat kelljen 
létrehoznunk, és helyet takarítanak meg. Ha azonban a szerkezet nem tükrözi az al- 
kalmazás igényelte felelősségláncot, a szükséges hivatkozásokat létre kell hoznunk. 
Az elemek összekötése. Ha nincsenek már létező hivatkozások a lánc létrehozásához, 
magunknak kell azokat elkészítenünk. Ebben az esetben a Kezelő (Handler) nem 
csak felületet biztosít a kérelmek kezeléséhez, hanem a Kezelkérelem (Handle- 
ReguesD) alapértelmezett megvalósításában hivatkozást is a következő jelöltre, 
amelyhez a kérelmet továbbítja. Ha valamelyik KonkrétKezelő alosztályra nem tarto- 
zik az adott kérelem, a továbbító műveletet nem kell felülbírálnia, hiszen az alapér- 
telmezett megvalósítás feltétel nélkül továbbít. 
Íme a SúgókKezelő (HelpHandler) alaposztály, amely a hivatkozást tartalmazza: 
class HelpHandler ( 


public: 
HelpHandler (HelpHandlert s) :  successor(s) () 
virtual void HandleHelp( ) ; 

private: 


HelpHandlert . successor; 
1; 


void HelpHandler: :HandleHelp() ( 
if ( successor) ( 
.Ssuccessor-oHandleHelp (( ) ; 


j 


A kérelmek ábrázolása. A kérelmek ábrázolására több lehetőségünk is van. A legegy- 
szerűbb, ha a kérelmet a kódba , drótozott" művelethívásként adjuk meg, mint ahogy 
a KezelSúgó (HandleHelp) esetében is tettük. Ez kényelmes és biztonságos, igaz, 
csak azok a kérelmek továbbíthatók így, amelyeket a Kezelő osztály meghatároz. 
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Egy másik lehetőség, hogy egyetlen kezelő függvényt írunk, ami paraméterként kap- 
ja meg a kérelem kódját (például egy egész számot vagy karakterlánco0. Ezzel a ké- 
relmek halmaza korlátlanul bővíthetővé válik; az egyetlen megkötés, hogy a küldő- 
nek és a fogadónak meg kell egyeznie a kérelem kódolásában. 

Ez a megközelítés rugalmasabb, de feltételes utasításokat igényel, amelyekkel a ké- 
relem a kódolásától függően továbbítható. Ezen kívül a paraméterek átadására nincs 
típusbiztos mód, vagyis magunknak kell be- és kicsomagolnunk azokat, ami nyil- 
vánvalóan kevésbé biztonságos, mintha közvetlenül hívnánk meg egy műveletet. 

A paraméter-átadási probléma megoldására önálló kérelemobjektumokat használha- 
tunk, amelyek összefogják a kérelem-paramétereket. A kérelmeket mondjuk egy 
Reguest (Kérelem) nevű osztály képviselheti, új kérelemtípusokat pedig úgy vehe- 
tünk fel, hogy alosztályokat származtatunk ebből az osztályból. Ezek az alosztályok 
aztán különböző típusú paramétereket határozhatnak meg. A kezelőknek ismerniük 
kell a kérelem típusát (vagyis hogy melyik Reguest alosztályt használják), hogy 
hozzáférhessenek a paraméterekhez. 

A kérelem azonosításához a Reguest meghatározhat egy elérő függvényt, ami az 
adott osztály azonosítóját adja vissza. Egy másik megoldás, hogy — amennyiben 
a megvalósításhoz használt nyelv támogatja — a fogadó a futásidejű típusinformáció- 
kat használja fel. 

íme egy továbbító függvény vázlata, amely a kérelmek azonosításához kérelemobjek- 
tumokat használ. A kérelem típusát a Reguest alaposztályban megadott GetKind 
(SzerezTípus) művelet határozza meg. 


void Handler: :HandleReguest (Reguest§ theReguest) ( 
switch (theReguest-5GetKind()) ( 
case Help: 
//az argumentum átalakítása a megfelelő típusra 
HandleHelp( (HelpReguestY) theReguest) ; 
break; 


case Print: 
HandlepPrint ( (PrintReguestY) theReguest) ; 
fŰras 
break; 


default: 
Tés: 
break; 
H 
pi 
Az alosztályok a továbbítást a HanáleReguest (Kezelkérelem) felülbírálásával bő- 
víthetik, így csak azokat a kérelmeket kezelik, amelyekre szakosodtak, a többit 
a szülőosztályhoz továbbítják. Ez a HandleReguest műveletnek hatékony bővítése 
(nem is felülírása). Lássunk egy példát, hogyan bővítheti egy ExtendedHandáler 
(Bővítettkezelő) nevű alosztály a Hanáler osztály HandleReguest-változatát: 
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class ExtendedHandler : public Handler ( 

public: 
virtual void HandleReguest(Reguest" the Reguest) ; 
Else 

1; 


void ExtendedHandler : :HandleReguest (ReguestY theReguest) ( 
switch (theReguest-5GetKind()) ( 
case Preview: 
//a Preview - Nyomtatási kép - kérelem kezelése 
break; 
default: 
//a többi kérelmet a Handler-re bízzuk 
Handler: :HandleReguest (theReguest ) ; 
) 
) 

4. Automatikus továbbítás (Smalltalk). A Smalltalkban a kérelmek továbbítására 
a doesNotUnderstand használható, melynek megvalósítása elfogja a megfelelő 
metódussal nem rendelkező üzeneteket. A docsNotUnderstanad felülbírálásával az 
üzenet az objektumot követő objektumhoz továbbítható, így a továbbítást nem szük- 
séges magunknak megvalósítanunk; az osztályok csak a hozzájuk tartozó kérelmeket 
kezelik, a többit a doesNotunderstand segítségével más osztályokhoz továbbítják. 


Példakód 


A következő példa azt illusztrálja, hogyan kezeli a felelősséglánc a súgórendszerhez inté- 
zett kérelmeket. Maga a súgókérelem itt konkrétan kifejezett művelet. A kérelmeket a lánc 
grafikus felületi elemei között a grafikus elemek hierarchiájában jelenlevő szülőhivatkozá- 
sok segítségével továbbítjuk, az egyéb elemek pedig a Kezelő (Handler) osztályban meg- 
határozott hivatkozás révén kapják meg. 


A HelpHandler (Súgókezelő) osztály a súgókérelmek kezelésének felületét határozza 
meg. Tartalmazza az alapértelmezett (üres) súgótémakört (help topic), illetve egy hivatko- 
zást a lánc következő súgókezelő elemére. A kulcsművelet a HanáleHelp (KezelSúgó), 
amelyet az alosztályok felülírnak. A HasHelp (VanSúgó) művelet célja, hogy kényelmeseb- 
bé tegye annak ellenőrzését, hogy létezik-e az adott elemhez hozzárendelt súgótémakör. 


typedef int Topic; 
const Topic NO HELP TOPIC - -1; 


class HelpHandler ( 
public: 
HelpHandler(HelpHandlert - 0, Topic - NO HELP TOPIC); 
virtual bool HasHelp(); 
virtual void SetHandler(HelpHandlert, Topic); 
virtual void HandleHelp() ; 
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private: 
HelpHandlert successor; 
Topic ,. topic; 

li; 


HelpHandler: :HelpHandler ( 
HelpHandler" h, Topic t 





) : . successor(h), , topic(t) ( ) 
bool HelpHandler asHelp() ( 
return topic !- NO HELP TOPIC; 


) 


void HelpHandler : : HandleHelp() ( 
if ( succéssor !- 0) ( 
.Successor-osHandleHelp(( ) ; 


§ 


Valamennyi grafikus elem a Widget (Vezérlő) elvont osztály alosztálya, ami viszont a 
HelpHandler alosztálya, hiszen a felhasználói felület valamennyi eleméhez tartozhat sú- 
gó. (Természetesen mixin alapú megvalósítást is használhattunk volna.) 
class Widget : public HelpHandler ( 
protected: 
Widget(Widgett parent, Topic t - NO HELP TOPIC); 
private: 
Widgett parent; 
1; 


Widget::Widget (Widgett w, Topic t) : HelpHandler(w, t) ( 
.-bparent - w; 


) 


Példánkban a lánc első kezelőeleme egy gomb (button). A Button osztály a Widget al- 


osztálya, konstruktora pedig két paramétert vár: egy hivatkozást az őt tartalmazó grafikus 
elemre, illetve a súgótémakört. 


class Button : public Widget ( 
public: 
Button(Widgett d, Topic t - NO HELP TOPIC); 


virtual void HandleHelp( ) ; 
// A Button által felülírt Widget műveletek... 


$7 
A Button Handlekelp-változata először ellenőrzi, hogy létezik-e súgótémakör a gom- 
bokhoz. Ha a fejlesztő nem adott meg ilyet, a kérelem a HelpHandler-ben meghatározott 
HandleHelp művelet segítségével továbbítódik a következő jelölthöz. Amennyiben létezik 
súgótémakör, a gomb megjeleníti azt, és a keresés befejeződik. 
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Button: :Button (Widget" h, Topic t) : Widget(h, t) ( ) 


void Button: :HandleHelp () ( 


if (HasHelp()) ( 
// súgó a gombhoz 
) else ( 


HelpHandler: :HandleHelp( ) ; 


$ 
A Dialog (Párbeszédablak) hasonló megoldást ad, de ekkor a következő jelölt nem egy 
másik grafikus elem, hanem bármilyen súgókezelő lehet. A bemutatott programban a jelölt 
az Application (Alkalmazás) osztály egy példánya lesz. 

class Dialog : public Widget ( 

public: 


Dialog(HelpHandlerY h, Topic t - NO HELP TOPIC); 
virtual void HandleHelp() ; 


// A Dialog által felülírt Widget műveletek... 
ésaz 
); 


Dialog::Dialog (HelpHandlert h, Topic t) : Widget(0) ( 
SetHandler(h, t); 
ú 


void Dialog: :HandleHelp () ( 


if (HasHelp()) ( 
// súgó a párbeszédablakhoz 
) else ( 


HelpHandler: :HandleHelp ( ) ; 
bi 
) 


A lánc végén az Application egy példánya áll. Az alkalmazás nem grafikus elem 
(Widge0, így az Application közvetlenül a HelpHandler osztályból származik. Amikor 
egy súgókérelem erre a szintre ér, az alkalmazás saját magáról szolgáltathat általános infor- 
mációkat, vagy felajánlhatja a súgótémakörök listáját: 
class Application : public HelpHandler ( 
public: 
Application(íTopic t) : HelpHandler(0, t) ( ) 


virtual void HandleHelp(( ) ; 
// az alkalmazáshoz tartozó műveletek... 
hi 


void Application: :HandleHelp () ( 
7// a súgótémakörök listájának megjelenítése 


) 
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Az alábbi kód létrehozza és összeköti az említett objektumokat. Párbeszédablakunk egy 
nyomtatási párbeszédablak, ezért az objektumokhoz a nyomtatással kapcsolatos témakö- 
rök tartoznak. 


const Topic PRINT TOPIC - 1; 
coönst Topic PAPER ORIENTATION TOPIC - 2; 
const Topic APPLICATION TOPIC - 3; 


Applicationt application - new Application(APPLICATION TOPIC) ; 
Dialogt dialog - new Dialog(application, PRINT TOPIC); 
Buttont button - new Button(dialog, PAPER ORIENTATION TOPIC) ; 


A súgó megjelenítésére irányuló kérelmet a HanáleHelp-et a lánc valamelyik objektumára 
meghívva adhatjuk ki. Ha a keresést a gombnál szeretnénk kezdeni, a gombra kell meghív- 
ni a műveletet: 


button-sHandleHelp ( ) ; 


Ebben az esetben a gomb azonnal kezelni fogja a kérelmet. Figyeljük meg, hogy a Dialog- 
ra bármelyik HelpHandler osztály következhet, sőt az, hogy a sorban melyik objektum 
következik, dinamikusan módosítható, így nem számít, melyik párbeszédablakot nyitottuk 
meg, mindenképpen a megfelelő környezetfüggő súgót indíthatjuk el. 


Ismert felhasználások 


A felhasználói események kezeléséhez számos osztálykönyvtár alkalmazza a Felelősség- 
lánc mintát. A Kezelő osztály neve ugyan különbözhet, de az alapgondolat ugyanaz: ami- 
kor a felhasználó kattint az egérrel vagy lenyom egy billentyűt, egy esemény váltódik ki, 
ami végigfut a láncon. A MacApp lApp89] és az ET--- (WGM881] az , eseménykezelő" (Event- 
Handler), a Symantec TCL könyvtára [Sym93b] az ,ügyintéző" (Bureaucra0), a NeXT 
AppkKiít-je IAdd94] pedig a , válaszoló" (Responder) nevet használja. 


A grafikus szerkesztőprogramok Unidraw keretrendszere parancs (Command) objektumo- 
kat határoz meg, amelyek a Component (Elem) és ComponentView (ElemNézet) objektu- 
mok felé irányuló kérelmeket zárják egységbe. A parancsok ilyen értelemben kérelmek, hi- 
szen az összetevők vagy nézetek egy művelet végrehajtásához ugyanúgy a Megvalósítás 
részben bemutatott , kérelmek mint objektumok" elv alapján értelmezik a kapott parancsot. 
Az elemek (Component) és nézeteik (ComponentView) hierarchikus rendbe állíthatók, 
melyben a parancs értelmezését az elemek a szülőjüknek továbbíthatják, ami aztán továb- 
bítja azt a saját szülőjének, és így tovább — vagyis előáll a felelősséglánc. 


Az ET4- a grafikus frissítéshez használja a Felelősséglánc mintát. Amikor egy grafikus ob- 
jektumnak frissítenie kell egy része megjelenítését, az InvalidateRect műveletet hívja meg, 
amit a grafikus objektumok maguk nem képesek kezelni, mert nem tudnak eleget saját kör- 
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nyezetükről. Előfordulhat például, hogy az objektum a kooordinátarendszerét átalakító 
Scroller (Gördítősáv) vagy Zoomer (Nagyító) objektumba ágyazódik, vagyis az objektum 
görgethető, illetve nagyítható, így egy része néha nem látható. Emiatt az InvalidateRect 
alapértelmezett megvalósítása a frissítési kérelmet továbbadja a befoglaló tároló objektum- 
nak. A továbbítási lánc utolsó tagja a Window (Ablak) osztály egy példánya. Amikor a kére- 
lem a Window-hoz ér, a frissítendő terület koordinátáinak megfelelő átalakítására már biz- 
tosan sor került. Az InvalidateRect műveletet a Window úgy kezeli, hogy értesítést küld az 
ablakkezelő rendszer felületének és frissítést kér. 


Kapcsolódó minták 


A Felelősséglánc mintát gyakran használják együtt az Összetétel mintával, ahol az elemek 
szülői jelentik a lánc következő elemét. 


Parancs 


Viselkedési objektumminta 
Cél 
A kérelmeket objektumokba zárjuk, aminek célja, hogy az ügyfeleknek paraméterként kü- 


lönböző kérelmeket adjunk át, ezeket sorba állítsuk vagy naplózzuk, illetve támogassuk 
a műveletek visszavonását. 


Egyéb nevek 


Command, Művelet, Akció (Action), Tranzakció (Transaction) 


Feladat 


Időnként szükséges lehet objektumokhoz anélkül intézni kérelmeket, hogy a kérelmezett 
műveletről vagy a kérelem fogadójáról bármilyen ismeretünk lenne. A felhasználói felületi 
eszköz- vagy elemkészletek például olyan objektumokat tartalmaznak, mint a gombok és 
menük, amelyek a felhasználó tevékenységétől függő műveleteket hajtanak végre (vagyis ké- 
relmeket teljesítenek). Maga az elemkészlet azonban nem adhat konkrét megvalósítást a ké- 
relmekhez magukban a gombokban és menükben, hiszen csak az adott elemkészletet hasz- 
náló alkalmazások tudják, melyik objektumnak mit kell csinálnia. Az elemkészlet fejlesztője 
nem ismerheti előre a kérelem fogadóját, illetve az általa végrehajtandó műveleteket. 


A Parancs tervezési minta lehetővé teszi az elemkészletek objektumainak, hogy meg nem 
határozott alkalmazás-objektumokhoz intézzenek kérelmeket, mégpedig úgy, hogy magu- 
kat a kérelmeket is objektumokká alakítják. Ezek az objektumok azután ugyanúgy tárolha- 
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tók és továbbadhatók, mint más objektumok. A minta kulcsa az elvont Parancs (Command) 
osztály, amely a műveletek végrehajtásához biztosít felületet. Legegyszerűbb formájában 
a felület egy elvont Végrehajt (Execute) műveletet tartalmaz. A konkrét Parancs alosztályok 
a fogadó példányváltozóként való tárolásával és a Végrehajt-nak a kérelmet meghívó meg- 
valósításával egy fogadó-művelet párt határoznak meg. A kérelem teljesítéséhez szükséges 
képességeket a fogadó tartalmazza. 


Alkalmazás lllkük Menü MenüElem 2———— ei Parancs 


Parancs 



































Hozzáad(Dokumentum) HozzáadíMenüElem) Kattintva)  ? Végrehajt() 
1 
Dokumentum parancs-5 Végrehajt() ői ásó f cócei 
Megnyit() 
Bezár() 
Kívág() 








Másol() 
Beilleszt() 


A Parancs objektumokkal a menük könnyen elkészíthetők, A menük (Menü, Menu) minden 
eleme a MenüElem (Menultem) osztály egy példánya. A menüket és elemeiket a felhaszná- 
lói felület egyéb részeivel együtt az Alkalmazás (Application) osztály hozza létre. Az Alkal- 
mazás osztály gondoskodik a felhasználó által megnyitott Dokumentum (Document) objek- 
tumok nyilvántartásáról is. 


Az alkalmazás minden menülemet valamelyik Parancs alosztály egy példányával állít elő. 
Amikor a felhasználó kiválasztja az egyik elemet, a MenüElem a hozzá tartozó parancsra 
meghívja a Végrehajt (Execute) műveletet, az pedig végrehajtja a parancsot. Maguk a me- 
nüelemek nem tudják, hogy a Parancs melyik alosztálya kapcsolódik hozzájuk. A Parancs 
alosztályok tárolják a kérelem fogadóját és meghívnak rá egy vagy több műveletet. 


A BeillesztParancs (Pastecommand) például szöveg beillesztését teszi lehetővé a vágólapról 
a dokumentumba. A parancs fogadója az a Dokumentum objektum, amelyet példányosítás- 
kor megkap, a Végrehajt művelet pedig a Beilleszt (Paste) parancsot a fogadó dokumentum- 
ra hívja meg. 





Dokumentum 





Megnyit() 
Bezárt) dokumentum 


Kivágú) Isa öészsávegesztesetézérű P 
Másol() BeillesztParancs 


Beilleszt() 

















Végrehajt  2------ ] B ZTTESESTETE 





dokumentum— Beilleszt) "a 
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A MegnyitParancs (OpenCommand) Végrehajt művelete ettől eltér: a felhasználótól egy do- 
kumentumnevet kér, létrehozza az ennek megfelelő Dokumentum objektumot, azt hozzá- 
adja a fogadó alkalmazáshoz, majd megnyitja a dokumentumot. 


Parancs 


Végrehajt() 











Alkalmazás 


Hozzáad(Dokumentum) 


Végrehajt)  ? 
KérFelhasználó) ! 


név — KérfFelhasználó() 
dokumentum — new Dokumentumínév) 


alkalmazás Hozzáad(dokumentum) 
dokumentum-3 Megnyit() 








Előfordulhat, hogy egy menüelemnek parancsok sorozatát kell végrehajtania. A dokumen- 
tumoldalt normál méretben középre helyező MenüElem például egy DokumentumKözépre- 
Parancs (CenterDocumentCommand) és egy NormálMéretParancs (NormalSizeCommand) 
objektumból épülhet fel. Miután a parancsok ilyetén összefűzése elég gyakori, egy Makró- 
Parancs (MacroCommand) nevű osztályt létrehozva lehetővé tehetjük, hogy a menüelemek 
korlátlan számú parancsot hajthassanak végre. 


A MakróParancs a Parancs konkrét alosztálya, amely egyszerűen parancsok sorozatát hajtja 
végre. Nincs kifejezetten megadott fogadója, mert az általa sorban végrehajtott parancsok 
meghatározzák saját fogadójukat. 





Parancs 
Végrehajt() I áá 




















parancsok 
MakróParancs Ft 


Végrehajt) ? 


a 


for all c in parancsok 
ce Végrehajt() 
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A fenti példák mindegyikében megfigyelhetjük, hogyan választja el a Parancs minta a műve- 
letet kezdeményező objektumot a művelet végrehajtásának képességével rendelkező objek- 
tumtól. Ez igen nagy rugalmasságot ad a felhasználói felület megtervezésében, hiszen így 
egy alkalmazásban egy szolgáltatáshoz menüt és parancsgombot is kapcsolhatunk, ha azok 
ugyanazon Parancs alosztály egy példányán osztoznak. A parancsok dinamikusan ki is cse- 
rélhetők, ami környezetfüggő helyi menük megvalósításánál jöhet jól, a parancsok nagyobb 
egységekben való egyesítésével pedig a parancssorozatok összeállítását támogathatjuk. 
Mindez azért lehetséges, mert a kérelmet kibocsátó objektumnak csak azt kell tudnia, ho- 
gyan adja ki a kérelmet; annak végrehajtási módjáról nem kell ismeretekkel rendelkeznie. 


Alkalmazhatóság 


A Parancs minta használata a következő esetekben célszerű: 


s Objektumoknak paraméterként egy végrehajtandó műveletet szeretnénk átadni, 
mint ahogy feljebb, a MenüElem objektumok esetében is tettük. Az ilyen paraméte- 
rezés módja az eljárásközpontú (procedurális) nyelvekben a visszahívható (callback) 
függvények használata. A visszahívható függvény olyan függvény, amit egy adott 
ponton bevezetünk, de később hívjuk meg. A parancsok a visszahívható függvények 
objektumközpontú megfelelői. 

e Kérelmeket különböző időpontokban szeretnénk meghatározni, sorba állítani, illet- 
ve végrehajtani. A Parancs objektumok élettartama független lehet az eredeti kére- 
lemtől. Ha a kérelem fogadóját címtér-független módon ábrázoljuk, a kérelemhez 
tartozó parancsobjektumot egy másik folyamathoz irányíthatjuk és ott teljesíthetjük 
a kérést. 

e Támogatni szeretnénk a művelet-visszavonást. A Parancs Végrehajt művelete hatásá- 
nak megfordításához állapotokat tárolhat. A Parancs felületnek rendelkeznie kell egy 
Visszavon (Unexecute) művelettel, ami megfordítja egy korábbi Végrehajt hívás hatá- 
sát. A végrehajtott parancsokat előzménylistában tároljuk. A korlátlan szintű visszavo- 
nást és ismételt végrehajtást úgy érjük el, hogy a Végrehajt, illetve a Visszavon hívásá- 
val előre-hátra bejárjuk ezt a listát. 

" Támogatni szeretnénk a változások naplózását, hogy rendszerösszeomlás esetén 
helyreállíthassuk a korábbi állapotot. Ha a Parancs felületet betöltő és tároló művele- 
tekkel egészítjük ki, következetes változásnaplót tarthatunk fenn. Az összeomlásból 
való helyreállítás abból áll, hogy a naplózott parancsokat visszatöltjük a lemezről, 
majd a Végrehajt művelettel újra végrehajtjuk azokat. 

. Egy programot alapműveletekből felépített magas szintű műveletekre szeretnénk 
alapozni. Az ilyen szerkezet gyakori a tranzakciókat támogató információs rendsze- 
rekben. A tranzakciók adatok változtatásainak halmazát zárják egységbe. A Parancs 
minta segítségével modellezhetjük a tranzakciókat, a parancsok közös felülete révén 
pedig minden tranzakciót egyformán hívhatunk meg. A minta azt is egyszerűbbé te- 
szi, hogy a rendszert új tranzakciókkal egészítsük ki. 
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Szerkezet 

Ügyfél Hívó 0 eg Parancs 

gi: Végrehajt() 

; bezsszásszzjet . . Fonjátó 

f fölröötázönzáátaaát fogadó 

! Műveletf) 16————— I  — KonkrétParancs 

; Végrehajt() . 0-- - - - - - - 77-11 fogadó—5 Műveletí) 7 

h-t etesen esetere efdlapt 
Résztvevők 

e Parancs 


— Felületet biztosít egy művelet végrehajtásához. 

KonkrétParancs (BeillesztParancs, MegnyitParancs) 

— Összeköt egy Fogadó (Receiver) objektumot és egy műveletet. 

-— A Fogadónak megfelelő művelet(ek) meghívásával megvalósítja a Végrehajt (Exe- 
cute) műveletet. 

Ügyfél (Alkalmazás) 

— Létrehoz egy KonkrétParancs (ConcreteCommand) objektumot és beállítja annak 
fogadóját. 

Hívó (MenüElem) 

— Felkéri a parancsot a kérelem teljesítésére. 

Fogadó (Dokumentum, Alkalmazás) 

- Tudja, hogyan kell végrehajtani az adott kérelemhez kapcsolódó műveleteket. 
Bármelyik osztály betöltheti a Fogadó szerepét. 


Együttműködés 


Az ügyfél létrehoz egy KonkrétParancs objektumot és meghatározza annak fogadóját. 
Valamelyik Hívó (Invoker) objektum elraktározza a KonkrétParancs objektumot. 

A Hívó a Végrehajt (Execute) műveletnek az adott parancsra való meghívásával kérel- 
met bocsát ki. Ha a parancsok visszavonhatók, a KonkrétParancs a Végrehajt meghí- 
vása előtt elraktározza a visszavonáshoz szükséges állapotot. 

A KonkrétParancs objektum a kérelem teljesítéséhez műveleteket hív meg a fogadóján. 


Az alábbi diagram az említett objektumok közötti együttműködést mutatja, illusztrálva, ho- 
gyan választja el a Parancs a hívót a fogadótól, illetve az utóbbi által teljesített kérelemtől. 
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egyFogadó —— egyÜgyfél egyParancs egyHívó 





new Parancs(egyFogadó) 


TárolParancs(egyParancs) 





























Művelet() végrehaitb 














fő —— 




















Következmények 


A Parancs minta előnyei a következők: 


1. A Parancs minta elválasztja a műveletet kezdeményező objektumot a művelet végre- 
hajtási módját ismerő objektumtól. 

2. A parancsok első osztályú objektumok, ugyanúgy kezelhetők és bővíthetők, mint 
bármely más objektum. 

3. A parancsokból parancsösszetételek alakíthatók ki. Ennek egyik példája a korábban 
említett MakróParancs osztály. Az összetett parancsok általában az Összetétel minta 
példái. 

4. Könnyű új parancsokat felvenni, mert a meglevő osztályokat nem kell módosítani, 

Megvalósítás 


A Parancs minta megvalósításával kapcsolatban a következő dolgok lényegesek: 


da 


Mennyire legyenek , intelligensek" a parancsok? Az egyes parancsok képességek szé- 
les körével rendelkezhetnek. Az egyik szélsőség az lehet, ha a parancs csupán össze- 
kapcsol egy fogadót a kérelem végrehajtásához szükséges műveletekkel, míg a másik 
az, ha maga valósít meg mindent, fogadó objektum bevonása nélkül. Az utóbbi akkor 
lehet hasznos, ha a meglevő osztályoktól független parancsokat szeretnénk meghatá- 
rozni, ha nincs megfelelő fogadó objektum, vagy ha a parancs egyébként is ismeri 
a fogadóját. Egy másik alkalmazás-ablakot létrehozó parancs például az ablak létre- 
hozásán kívül más objektumok készítésére is képes lehet. A két szélsőség között az 
olyan parancsok találhatók, amelyek éppen elegendő ismerettel rendelkeznek ahhoz, 
hogy dinamikusan megtalálják a fogadójukat. 
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2. A visszavonás és újbóli végrehajtás támogatása. A parancsobjektumok akkor képe- 
sek támogatni a visszavonást és újbóli végrehajtást, ha rendelkeznek valamilyen 
módszerrel (például Visszavon vagy Mégse — Unexecute, Undo — művelettel) a vég- 
rehajtás , megfordítására". A KonkrétParancs osztályoknak ehhez általában az állapo- 
tot is tárolniuk kell. Az állapot a következőket rögzíti: 

e a Fogadó objektumot, amely ténylegesen végrehajtja a kérelem teljesítéséhez 
szükséges műveleteket, 

s a fogadón végrehajtott művelet argumentumait, 

s a fogadó azon eredeti értékeit, amelyek a kérelem kezelése következtében meg- 
változhatnak. A fogadónak biztosítania kell azokat a műveleteket, amelyek segít- 
ségével a parancs a fogadót visszaállíthatja a korábbi állapotba. 

Ha csak egyszeri visszavonást akarunk támogatni, elég, ha az alkalmazás csak az 
utoljára végrehajtott parancsot tárolja. A többszintű visszavonáshoz, illetve ismétlés- 
hez viszont a programnak a végrehajtott parancsok előzményjlistájára van szüksége, 
amelynek lehetséges hossza határozza meg, hány műveletet vonhatunk vissza. 
Az előzménylista parancssorozatokat tárol; ha a sorban visszafelé haladunk és 
, visszafordító" műveleteket hajtunk végre, töröljük a hatást, ha pedig előre, akkor új- 
ból végrehajtjuk a parancsokat. 
Előfordulhat, hogy a visszavonható parancsokról az előzménylistára történő felvétel 
előtt másolatot kell készíteni. Erre akkor lehet szükség, ha az eredeti — mondjuk egy 
menüelemtől érkező — kérelmet teljesítő parancsobjektummal később más művele- 
teket kívánunk végrehajtatni. Ha az objektum állapota a különböző hívásoknál más 
és más lehet, a másolás biztosítja, hogy a különböző változatokat meg tudjuk külön- 
böztetni. 

Egy kijelölt objektumokat törlő TörölParancs (Deletecommand) objektumnak pél- 

dául minden végrehajtásnál különböző objektumokat kell tárolnia, ezért a Töröl- 

Parancs-ról a végrehajtás után másolatot kell készíteni, és ezt a másolatot helyezzük 

majd az előzménylistára. Ha egy adott parancs állapota sohasem változik, a másolás 

nem szükséges; ebben az esetben elég, ha az előzménylistában egy hivatkozást he- 
lyezünk el a parancsra. A listára helyezés előtt másolandó parancsok prototípusként 
viselkednek. (Lásd a Prototípus tervezési mintát a 3. fejezetben.) 

3. A hibahalmozódás elkerülése a visszavonások során. Amikor egy megbízható, a jelen- 
tést megőrző visszavonási—ismétlési rendszert próbálunk kialakítani, az állapothiba 
gondot okozhat. Ahogy parancsokat hajtunk végre, vonunk vissza és ismétlünk meg, 
a hibák halmozódhatnak, és az alkalmazás állapota végül eltérhet az eredeti értékek- 
től. Ennek elkerülése érdekében további információkat kell tárolnunk a parancsobjek- 
tumokban, hogy az eredeti állapotba való visszaállítást biztosíthassuk. Ebben segíthet 
az Emlékeztető tervezési minta, amelynek révén a parancsok anélkül férhetnek hozzá 
ezekhez az információkhoz, hogy más objektumok belső szerkezetét felfednék. 

4. C-xx4 sablonok használata. A (1) vissza nem vonható, illetve (2) az argumentumokat 
nem igénylő parancsokhoz Cr sablonokat használhatunk, így elkerülhetjük, hogy 
minden művelethez és fogadóhoz újabb Parancs alosztályt kelljen létrehoznunk. 
A Példakód részben megmutatjuk, hogyan. 
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Példakód 


Az alább bemutatott C:-- kód a Feladat részben bevezetett Parancs (Command) osztályok 
megvalósítását vázolja fel; az Opencommand, PasteCommand és MacroCommand (Megnyit- 
Parancs, BeillesztParancs és MakróParancs) meghatározására kerül sor. Először persze az el- 
vont Command osztályt kell elkészítenünk: 


class Command ( 
public: 


virtual 7Commanad( ) ; 


virtual void Execute() - 0; 
protected: 

Command ( ) ; 
1; 


Az Opencommanad a felhasználó által megadott nevű dokumentumot nyitja meg. Konstruk- 
torában egy Application (Alkalmazás) objektumot kell átadnunk neki. A megnyitandó 
dokumentum nevének megadására az AskUser (KérFelhasználó) eljárás kéri meg a fel- 
használót. 


class OpenCommand : public Command ( 
public: 
OpenCommand (Applicationt) ; 


virtual void Execute(); 
protected: 

virtual const char! AskUser(); 
private: 

Applicationt application; 

chart response; 
19 


OpenCommand : : penCommand (Applicationt a) ( 
.-application - a; 


) 


void OpenCommana: : Execute () ( 
const char!" name - AskuUser-(); 


if (name !- 0) ( 
Document! document - new Document (name) ; 
.application-sAdd (document ) ; 
document-50Open ( ) ; 
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A PasteCommand egy Document (Dokumentum) objektumot vár, ami a fogadója lesz. 
A fogadót paraméterként adjuk át a PasteCommand konstruktorának. 


elass PasteCommand : public Command ( 
public: 
PasteCommand ( Document" ) ; 


virtual void Execute(); 
private: 
Documentt document; 


1; 


PasteCommand: : PasteCommand (DocumentY doc) ( 
-document - doc; 


) 


void PasteCommand: : Execute () ( 
-document-sPaste() ; 


Az egyszerű — vissza nem vonható és argumentumot nem váró — parancsokhoz osztálysab- 
lont használhatunk, így a parancs fogadóját paraméterként adhatjuk át. Az ilyen parancsok 
számára hozzuk létre a SimpleCommand (EgyszerűParancs) sablon alosztályt, amelynek 
paramétere a Receiver (Fogadó) típusa, feladata pedig a kapcsolat fenntartása a fogadó 
objektum és egy művelet között, amelyet egy tagfüggvényt címző mutatóként tárolunk. 


template cclass Receivers 
class SimpleCommand : public Command ( 
public: 

typedef void (Receiver::$ Action) (); 


SimpleCommand(Receivert r, Action a) 
.receiver(r), . action(a) ( ) 


virtual void Execute(); 
private: 
Action ,. action; 
Receiver" , receiver; 
b; 


A konstruktor a fogadót és a műveletet a megfelelő példányváltózókban tárolja, az 
Execute (Végrehajt) pedig egyszerűen végrehajtja a műveletet a fogadón. 


template cclass Receivers 
void SimpleCommandcReceiver5: :Execute () ( 
( féctivér-ot action) (); 


) 
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Ahhoz, hogy létrehozzon egy parancsot, amely a MyClass (SajátOsztály) osztály egy pél- 
dányára meghívja az Act ion-t (Művelet), az ügyfél a következő kódot tartalmazza: 


MyClasst receiver - new MyClass; 
FT ak a 
Commandt aCommand - 


new SimpleCommandcMyClasss(receiver, gMyClass::Action) 
ELL 


aCommand-—5Execute( ) ; 


Ne feledjük, hogy ez a megoldás csak az egyszerű parancsok esetében működik. Az össze- 
tettebb parancsok, amelyek nem csupán fogadójukat tartják nyilván, hanem más argumen- 
tumokat, illetve a visszavonási állapotot is, a command alosztályai kell legyenek. 


A MacroCommana parancsok sorozatát kezeli, illetve műveleteket biztosít a parancssorozat 
bővítésére és szűkítésére. Fogadóra itt kifejezetten nincs szükség, hiszen az egyes 
valparancsok" meghatározzák a saját fogadójukat. 


class MacroCommand : public Command ( 
public: 
MacroCommana ( ) ; 


virtual "MacroCommanad-( ) ; 


virtual void Add(Command" ) ; 
virtual void Remove (Commandt ) ; 


virtual void Execute(); 
private: 

ListcCommandtoat — cmds; 
hi 


A MacroCommand működésének kulcsa az Execute tagfüggvény, amely bejárja a parancs- 
sorozat elemeit és egyesével végrehajtja rajtuk az Execute műveletet. 


void MacroCommand: :Execute () ( 
ListIteratorcCommandts5 i( cmds) ; 


for (i.First(); !i.IsDone(); i.Next()) ( 
Commandt c - i.Currentiltem-( ) ; 
€-sExecute(); 


Megjegyzendő, hogy amennyiben a MacroCommand megvalósítja az Unexecute (Vissza- 


von) műveletet, az egyes parancselemek visszavonására az Execute megvalósításához ké- 
pest fordított sorrendben van szükség. 
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Végül, a MacroCommana-nak rendelkeznie kell a parancselemek kezeléséhez, köztük az 
azok törléséhez szükséges műveletekkel. 


void MacroCommand::Add (Commandr c) ( 
.-cmds-sAppend (c) ; 
) 


void MacroCommand: :Remove (Commandt c) ( 
.Ccmds-5Remove (c); 


Ji 


Ismert felhasználások 


A Parancs minta valószínűleg Lieberman dolgozatában ILie85] bukkant fel először. A vissza- 
vonható műveletek parancsokkal való megvalósításának ötletét az Apple [IApp89] tette nép- 
szerűvé. Az ET-t-4 IWGM8g], az InterViews [LCI--92] és a Unidraw [VL90] szintén tartalmaz- 
nak olyan osztályokat, amelyek a Parancs mintát követik. Az InterViews Action (Művelet) 
elvont osztálya parancsszolgáltatásokat biztosít, az ActionCallback (MűveletVisszahívás) 
sablon pedig, amelynek paramétere egy műveleti függvény, automatikusan képes példá- 
nyosítani a parancs-alosztályokat. 


A THINK osztálykönyvtár ISym93bl] ugyancsak parancsokat használ a visszavonható műve- 
letek támogatására. A parancsokat a THINK , feladatoknak" (Task) nevezi. A feladatobjektu- 
mok egy Felelősségláncon haladnak végig. 


A Unidraw parancsobjektumai abban az értelemben egyediek, hogy üzenetként viselkedhet- 
nek. A Unidraw parancsok értelmezés céljából más objektumokhoz küldhetők, az értelmezés 
pedig a fogadó objektumtól függően változhat. A fogadó emellett át is ruházhatja az értelme- 
zés feladatát egy másik objektumra, ami jellemzően a szülője egy nagyobb szerkezetben, pél- 
dául egy Felelősségláncban. A Unidraw parancsok fogadói így tulajdonképpen , számított" és 
nem tárolt fogadók. Az értelmezés módja a futásidejű típusinformációktól függ. 


Coplien leírja ICop92], hogyan készíthetünk funktorokat, vagyis függvényobjektumokat 
a Ctt-ban. Használatukat a függvényhívó operátor (operator ( ) ) túlterhelésével részben 


elrejti. A Parancs minta azonban ettől eltér, hiszen középpontjában a fogadó és a függvény 
(vagyis a művelet) összekötése, és nem csupán egy függvény biztosítása áll. 


Kapcsolódó minták 
A MakróParancsok megvalósításához az Összetétel minta használható. 


Az Emlékeztető minta segítségével a parancs által a hatásának visszavonásához igényelt ál- 
lapotot tárolhatjuk. 


A listára helyezés előtt másolandó parancsok Prototípusként viselkednek. 
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Értelmező 


Viselkedési osztályminta 


Egyéb nevek 


Interpreter 
Cél 


Egy adott nyelv nyelvtanát ábrázoljuk, illetve ehhez az ábrázoláshoz értelmezőt biztosí- 
tunk, amely annak alapján képes a nyelv mondatait megérteni. 


Feladat 


Ha egy bizonyos típusú probléma rendszeresen felbukkan, célszerű lehet egy egyszerű 
nyelv mondataiként megfogalmazni a probléma előfordulási lehetőségeit, majd egy értel- 
mezőt készíteni, amely e mondatok értelmezésével megoldja a problémát. 


Gyakori feladat például, hogy bizonyos mintákra illeszkedő karakterláncokat keressünk. 
A karakterlánc-minták meghatározásának szabványos nyelvét a szabályos kifejezések 
(regular expressions) jelentik. Ha a kereső algoritmusok a keresendő karakterláncokat leíró 
szabályos kifejezéseket értelmezik, elkerülhetjük, hogy minden minta-karakterlánc párosí- 
táshoz külön algoritmust kelljen írnunk. 


Az Értelmező tervezési minta annak módszerét adja meg, hogyan határozhatjuk meg egy 
egyszerű nyelv nyelvtanát, hogyan ábrázolhatjuk a nyelv mondatait, és hogyan értelmez- 
hetjük ezeket a mondatokat. Az említett esetben a minta a szabályos kifejezések nyelvtaná- 
nak leírását, adott szabályos kifejezések ábrázolását, illetve azok értelmezését segíti. 


Tegyük fel, hogy az alábbi nyelvtan határozza meg a szabályos kifejezéseket: 





kifejezés ::- literál I választás I sorozat ] ismétlés I 
"(" kifejezés ")" 

választás ::- kifejezés !]" kifejezés 

sorozat kifejezés "§! kifejezés 





ismétlés 
literál 


kifejezés "rt! 
tél all ls l l ll ETT lel. dől e inet dl E 


A kezdőszimbólum a kifejezés (expression) a zárószimbólum pedig az alapszavakat 
meghatározó literá1 (litera)). 
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Az Értelmező mintában minden nyelvtani szabályt egy-egy osztállyal ábrázolunk. A szabály 
jobb oldalán álló szimbólumok ezen osztályok példányai. A fenti nyelvtant öt osztállyal áb- 
rázolhatjuk: a SzabályosKifejezés (RegularExpression) elvont osztállyal, és annak négy al- 
osztályával (Literálkifejezés, VálasztásKifejezés, SorozatKifejezés, IsmétlésKifejezés — vagyis 


LiteralExpression, AlternationExpression, SeguenceExpression és RepetitionEx; 
Az utolsó három osztály alkifejezéseket tartalmazó változókat határoz meg. 








pression). 














I 
Literálkifejezés 






































Értelmez) 
literál 
alés IsmétlésKifejezés  ) VálasztásKifejezés iszt 








Értelmezl) ] Értelmezl) 

















A nyelvtan által meghatározott valamennyi szabályos kifejezést egy, az osztályok példánya- 


iból felépülő elvont szintaxisfa ábrázolja. 


egySorozatkifejezés 


kifejezés1 


kifejezés2 













! egyliterálkifejezés 


"raining! 


Tr egyismétléskifejezés 


ismétlése 


egyVálasztásKifejezés 


lehetőség! 
lehetőség2 









egyliterálkifejezés 





egyliterálkifejezés 








"I "dogs" ( "cats" 
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A fenti szintaxisfa például a következő szabályos kifejezésnek felel meg: 


raining §£ (dogs I] cats) § 


A szabályos kifejezésekhez úgy készíthetünk értelmezőt, ha a SzabályosKifejezés (Regular- 
Expression) minden alosztályára meghatározzuk az Értelmez (Interpre) műveletet. Az Ér- 
telmez argumentumként azt a környezetet várja, amelyben a kifejezést értelmeznie kell. 
A környezet a bemenő karakterláncot jelenti, illetve azt, hogy a karakterlánc mekkora ré- 
szét próbálták már a mintához illeszteni. A SzabályosKifejezés alosztályai az Értelmez mű- 
veletet úgy valósítják meg, hogy az adott környezet alapján a bemenő karakterlánc követ- 
kező részét vizsgálják. Lássunk néhány példát: 


. Aliterálkifejezés azt ellenőrzi, hogy a bemenet illeszkedik-e az általa meghatározott 
literálra. 

e A VálasztásKifejezés azt ellenőrzi, hogy a bemenet illeszkedik-e bármelyik választási 
lehetőségre. 

". Az IsmétlésKifejezés azt ellenőrzi, hogy a bemenet tartalmaz-e ismétlődő kifejezést. 


Alkalmazhatóság 


Az Értelmező minta használata akkor célszerű, ha van értelmezhető nyelv, amelynek kifeje- 
zéseit elvont szintaxisfában ábrázolhatjuk. Az Értelmező minta a következő helyzetekben 
alkalmazható a legnagyobb sikerrel: 


e A nyelvtan egyszerű. A bonyolult nyelvtanok osztályhierarchiája túl nagy és kezelhe- 
tetlen lehet; ezek esetében az elemző generátorok és hasonló eszközök jobb megol- 
dást kínálnak, mert elvont szintaxisfa felépítése nélkül képesek értelmezni a kifeje- 
zéseket, amivel helyet és valószínűleg időt takaríthatunk meg. 

e A hatékonyság nem létfontosságú szempont. A leghatékonyabb értelmezők általá- 
ban nem közvetlenül elemzik a fákat, hanem először más formára alakítják azokat. 
A szabályos kifejezéseket például gyakran alakítják állapotautomatákká. Mindazon- 
által a fordító ekkor is megvalósítható az Értelmező minta segítségével. 
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Szerkezet 


Ügyfél 








szzezzzáznt.  eészezz segyzz 


TerminálisKifejezés NemterminálisKifejezés 





Értelmezíkörnyezet) 








Résztvevők 


ElvontkKifejezés (SzabályosKifejezés) 

— Egy elvont Értelmez (Interpret) műveletet vezet be, ami az elvont szintaxisfa min- 
den csomópontjára közös. 

TermináliskKifejezés (Literálkifejezés) 

— A nyelvtan terminálszimbólumaihoz kapcsolódó Értelmez műveletet valósítja 
meg. 

— A mondatok minden egyes terminálszimbólumához egy-egy példány szükséges. 

NemtermináliskKifejezés (VálasztásKifejezés, IsmétlésKifejezés, SorozatKifejezés) 

— A nyelvtan minden R ::— R1R2. . . R,, szabályához egy-egy ilyen osztály szükséges. 

— Az R1-től az R,-ig minden szimbólumhoz egy-egy ElvontKifejezés (Abstract- 
Expression) típusú példányváltozót biztosít. 

— Megvalósítja a nyelvtan nemterminális szimbólumaihoz kapcsolódó Értelmez mű- 
veletet. Az Értelmez jellemzően ismételten önmagát hívja meg az R1-R,, szimbólu- 
mokat jelképező változókra. 


Környezet 
— Az értelmező globális környezetéről tartalmaz információkat. 
Ügyfél 


-— A nyelvtan által meghatározott nyelv egy adott mondatát ábrázoló elvont szinta- 
xisfát épít fel (vagy kap meg). A fa a NemterminálisKifejezés (NonterminalExpres- 
sion) és a TerminálisKifejezés (TerminalExpression) osztályok példányaiból áll. 

— Meghívja az Értelmez műveletet. 
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Együttműködés 


Az ügyfél felépíti (vagy megkapja) a mondatot, egy NemterminálisKifejezés és 
TerminálisKifejezés példányokból álló elvont szintaxisfa formájában, majd előkészíti 
a környezetet és meghívja az Értelmez műveletet. 

A NemterminálisKifejezés csomópontok mindegyike az alkifejezéseknek megfelelő- 
en határozza meg az Értelmez műveletet. A TerminálisKifejezések Értelmez művelete 
az alapesetet határozza meg. 

Az egyes csomópontokban levő Értelmez műveletek a Környezet (Context) segítsé- 
gével tárolják és érik el az értelmező állapotát. 


Következmények 


Az Értelmező minta előnyei és hátrányai a következők: 
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4. 


A nyelvtan könnyen módosítható és bővíthető. Mivel a minta a nyelvtani szabályokat 
osztályokkal ábrázolja, a nyelvtant örökléssel módosíthatjuk vagy bővíthetjük. 
A meglevő kifejezések fokozatosan módosíthatók, az újakat pedig a régiek változa- 
taiként határozhatjuk meg. 

A nyelvtan megvalósítása is könnyű. Az elvont szintaxisfa csomópontjait meghatáro- 
zó osztályok megvalósítása hasonló; az osztályok könnyen megírhatók, sőt, létreho- 
zásuk fordítóprogram- vagy elemzőgenerátor segítségével automatizálható is. 


. A bonyolult nyelvtanok fenntartása nehéz. Az Értelmező minta nyelvtani szabályon- 


ként legalább egy osztályt határoz meg. (Ha a szabályokat BNF formában adjuk meg, 
több osztályra is szükség lehet.) Ennélfogva a sok szabályból álló nyelvtanok kezelé- 
se nehéz. A probléma enyhítésére használhatunk más tervezési mintákat (lásd 
a Megvalósítás részt), de ha a nyelvtan nagyon bonyolult, az olyan megoldások, mint 
a fordító- vagy elemzőgenerátorok használata célszerűbb lehet. 

A kifejezések értelmezésére könnyű új módszereket hozzáadni. Az Értelmező minta 
egyszerűbbé teszi, hogy a kifejezéseket új módon értékeljük ki. Ha egy adott kifeje- 
zés osztályára új műveletet határozunk meg, támogathatjuk például a típusellenőr- 
zést. Ha a kifejezések értelmezési módját gyakran változtatjuk, érdemes a Látogató 
mintát alkalmazni, hogy elkerüljük a nyelvtani osztályok módosítását. 


Megvalósítás 


Az Értelmező és az Összetétel minta a megvalósítás módjában számos szempontból hason- 
lít. Az alábbiak viszont kifejezetten az Értelmező mintához kapcsolódnak: 


Lk 


Elvont szintaxisfa építése. Az Értelmező minta nem magyarázza el, hogyan hozhat- 
juk létre az elvont szintaxisfát, vagyis az elemzéssel (parsing) nem foglalkozik, A fa 
létrehozható táblavezérlésű elemzővel, ,kézi" (általában rekurzív ereszkedő) elem- 
zővel, illetve közvetlenül az ügyfél által. 
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2. Az Értelmez művelet meghatározása. A kifejezésosztályokban nem kell meghatároz- 
nunk az Értelmez műveletet. Ha gyakran készítünk új értelmezőt, érdemesebb a Lá- 
togató mintát alkalmazni és a műveletet külön , látogató" objektumba helyezni. Egy 
programozási nyelv nyelvtana például számos műveletet végez az elvont szintaxisfá- 
kon (típusellenőrzést, hatékonyságnövelést, kód-előállítást stb.). Ahhoz, hogy elke- 
rüljük, hogy minden nyelvtani osztályhoz meg kelljen határoznunk ezeket a művele- 
teket, célszerűbb látogatót alkalmaznunk. 

3. A terminálszimbőlumok megosztása a Pehelysúlyű mintával. Azon nyelvtanok eseté- 
ben, amelyek mondatai egy adott terminálszimbólum számos előfordulását tartalmaz- 
zák, érdemes a szimbólum egyetlen másolatát megosztani. A számítógépprogramok 
nyelvtanai jó példák erre — gondoljunk csak a kódban számos helyen felbukkanó válto- 
zókra. A Feladat részben leírt példa mondataiban a dog terminálszimbólum (amit a Li- 
terálkifejezés osztály ábrázol) fordulhat elő többször. A terminális csomópontok általá- 
ban nem tárolnak információt az elvont szintaxisfában elfoglalt helyükről; az értelme- 
zéshez szükséges környezetet a szülőcsomópontok adják át nekik. Így megkülönbözte- 
tünk megosztott (belső) és átadott (külső) állapotokat, és alkalmazhatjuk a Pehelysúlyú 
mintát. Például a Literálkifejezés minden dog példánya megkapja a környezetet, ami az 
addig mintára illesztett karakterlánc-részt tartalmazza. Ezután minden ilyen Literál- 
Kifejezés ugyanazt csinálja az Értelmez műveletben: ellenőrzi, hogy a bemenet követ- 
kező része tartalmaz-e dog-ot, függetlenül attól, hol helyezkedik el a példány a fában. 


Példakód 


íme két példa; az első egy teljes program Smalltalk nyelven, ami ellenőrzi, hogy egy karak- 
tersorozat illeszkedik-e egy adott szabályos kifejezésre, a második egy logikai (Boolean) ki- 
fejezéseket értékelő C-t program. 


A szabályos kifejezésre illesztő program azt vizsgálja, hogy egy adott karaktersorozatot 
meghatároznak-e a nyelv szabályos kifejezései. A szabályos kifejezések nyelvtana a követ- 
kező (ezúttal angolul: 


expréssion ::- literal ] alternation I] seguence ] repetition I 
"(! expression !)! 

alternation ::- expression !"]" expression 

sedguence ::- expression "§! expression 

repetition ::- expression "repeat" 

lítaral sez tat etet Lt avn EAT RT EST] cs 


Ez a nyelvtan a Feladat részben szereplő példa némileg módosított változata. Azért volt 
szükség a változtatásra, mert a Smalltalk-ban a " "" szimbólum nem lehet utótagos (postfix) 
művelet; így ezt a repeat-re cseréltük. 


(("dog! I "cat!") repeat § "weather") 


A fenti szabályos kifejezés például a "dog dog cat weather" bemenő karakterláncnak 
felel meg. 
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Az illesztő megvalósításához a pár oldallal korábban bemutatott öt osztályt határozzuk meg. 
A SeguenceExpression (Sorozatkifejezés) osztály példányváltozói az expressionl 
(kifejezés1) és az exoression2 (kifejezés2), amelyek az osztály gyermekeit jelölik az elvont 
szintaxisfában. Az AlternationExpression (VálasztásKifejezés) a választási lehetőségeket 
az alternativel (lehetőség1) és alternative2 (lehetőség2) példányváltozókban tárolja, 
míg a RepetitionExpression (IsmétlésKifejezés) az ismétlendő kifejezést a repetition 
(ismétlés) változóban, a LiteralExpression (Literálkifejezés) components (elemek) pél- 
dányváltozója pedig objektumok (valószínűleg karakterek) listáját tartalmazza, amelyek azt 
a literális karakterláncot jelölik, aminek illeszkednie kell a bemenő karaktersorozatra. 


A match: CGillesz0 művelet a szabályos kifejezés értelmezője, amit az elvont szintaxisfát 
meghatározó valamennyi osztály megvalósít. Argumentuma az inputState (bemenet- 
Állapot), ami az illesztési folyamat aktuális állapotát jelöli a bemenő karakterlánc egy részé- 
nek elolvasása után. 


Ezt az állapotot bemeneti folyamok jellemzik, amelyek a szabályos kifejezés által elfogad- 
ható bemeneteket ábrázolják. (Ez nagyjából megfelel annak, mintha egy egyenértékű vé- 
ges állapotú automata minden lehetséges állapotát rögzítenénk az adott pontig, a bemenő 
adatfolyam felismerése során.) 


Az aktuális állapot a repeat (ismétel) művelet szempontjából a legfontosabb. Tegyük fel, 
hogy a szabályos kifejezés a következő: 


"a"! repeat 


Ekkor az értelmező illeszkedőként értelmezi az "a", "aa", "aaa" stb. sorozatokat. 
Ha a szabályos kifejezés azonban ez: 


"ta" repeat § "bc! 


Az illeszkedő sorozatok máris az "abc", "aabc", "aaabc" és így tovább. Nézzünk egy má- 
sik változatot: 


"a" répőat §£ "ápet 


Az "aabc" bemenet illesztése az " "a" repeat" alkifejezéshez ekkor két bemenő folya- 
mot eredményez, amelyek közül az egyik a bemenet egy karakterét, míg a másik annak két 
karakterét vizsgálta már meg. Csak az egy karaktert elfogadó folyam fog illeszkedni a mara- 
dék "abc"-re 


Most nézzük a szabályos kifejezést meghatározó osztályok mindegyikére a match: megha- 
tározását. A SeguenceExpression meghatározása sorban minden alkifejezésére vizsgálja 
az illeszkedést, a bemenő folyamokat pedig általában eltávolítja az input State-ből. 


Értelmező 


255 





match: inputState 
" expression2 match: (expressionl match: inputState). 


Az AlternationExpression-ök az egyes választási lehetőségek állapotának uniójából 
álló állapotot adnak vissza. A match: meghatározása az AlternationExpression ese- 
tében a következő: 


match: inputState 
Il finalState I 
finalState :- alternativel match: inputState. 
finalState addAll: (alternative2 match: inputState). 
" finalState 


A RepetitionExpression match: művelete annyi esetleg illeszkedő állapotot próbál 
találni, amennyit csak lehet: 


match: inputState 
Il astate finalState I 


aState :- inputState. 
finalState :- inputState copy. 
[laState isEmpty] 
whileFalse: 
IaState :- repetition match: aState. 


finalState addAll: aStatej]. 
" finalState 


A kimeneti állapot általában több állapotot tartalmaz, mint a bemeneti, mert a Repe- 
titionExpression a repetition egy, kettő vagy több előfordulását előfordulását il- 
lesztheti a bemenetre. A bemeneti állapotok e lehetséges állapotokat ábrázolják, így a sza- 
bályos kifejezés következő elemei eldönthetik, melyik állapot a helyes. 


A LiteralExpression match: művelete a kifejezés összetevőit megpróbálja minden le- 
hetséges bemeneti adatfolyamra ráilleszteni, és csak azokat a folyamokat tartja meg, ame- 
lyekben illeszkedést talál: 


match: inputState 
Il finalState tStream I 


finalState :- Set new. 
inputState 
do: 
[:stream I] tStream :- stream copy. 


(tStream nextAvailable: 
components size 
) - components 
ifTrue: [finalState add: tStream)] 
fs 
" finalState 
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A bemeneti adatfolyamot a nextAvailable : (következőElérhető) üzenet lépteti előre; ez 
az egyetlen léptető match : művelet. Figyeljük meg, hogy a visszakapott állapot a bemene- 
ti adatfolyam másolatát tartalmazza, ezáltal biztosítva, hogy egy illeszkedő literál soha ne 
változtassa meg az adatfolyamot. Ez azért fontos, mert az AlternationExpression lehe- 
tőségeinek a bemenő adatfolyam azonos példányait kell látniuk. 


Most, hogy meghatároztuk az elvont szintaxisfát felépítő osztályokat, leírhatjuk a felépítés 
módját. Nem írunk elemzőt a szabályos kifejezésekhez, inkább meghatározunk néhány 
műveletet a RegularExpression osztályokhoz. Így a Smalltalk kifejezések kiértékelése 
a megfelelő szabályos kifejezés elvont szintaxisfáját eredményezi, és ugyanúgy használhat- 
juk a Smalltalk beépített fordítóját, mintha a szabályos kifejezések elemzője lenne. 


Az elvont szintaxisfa felépítéséhez az "1", a "repeat", illetve az "a " szimbólumokat 
a RegularExpression műveleteiként meg kell határoznunk. Az osztályban a meghatáro- 
zások a következőképpen néznek ki: 


§ aNode 
" SeguenceExpression new 
expressionl: self expression2: aNode asRExp 


repeat 
" RepetitionExpression new repetition: self 


I aNode 
" AlternationExpression new 
alternativel: self alternative2: aNode asRExp 


asRExp 
" self 


AZ asRExp művelet a literálokat RegularExpression-ökké alakítja. Ezeket a művelete- 
ket a String (Karakterlánc) osztályban határozzuk meg: 


§ aNode 
" SeguenceExpression new 
expressionl: self asRExp expression2: aNode asRExp 


repeat 
" RepetitionExpression new repetition: self 


I aNode 
" AlternationExpression new 
alternativel: self asRExp alternative2: aNode asRExp 


asRExp 
" LiteralExpression new components: self 
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Ha ezeket a műveleteket az osztályhierarchia magasabb fokán határoznánk meg (Seguen- 
ceableCollection a Smalltalk-80-ban, IndexedCollection a Smalltalk/V-ben), akkor 
az olyan osztályokra is érvényesek lennének, mint az Array vagy az Orderedcollection, 
így a szabályos kifejezéseket bármilyen objektumból álló sorozatokra illeszthetnénk. 


A második példa egy logikai (Boolean) kifejezéseket kezelő és kiértékelő program, C---- 
nyelven megvalósítva. E nyelv terminálszimbólumai logikai változók, vagyis a true és 
false állandók. A nemterminális szimbólumok az ana, or és not operátorokat tartalmazó 
kifejezéseket jelölik. A nyelvtan meghatározása a következő : " 








BooleanExp ::- VariableExp I Constant !] OrExp I AndExp I] NotExp I! 
"(!" BooleanExp !")! 

AndExp ::- BooleanExp "and"! BooleanExp 

OrExp BooleanExp "or! BooleanExp 

NotExp "not"! BooleanExp 

Constant ::- "true"! l] "false" 

Vári áALEEE fe RT BT vé] e tre lg 


A logikai kifejezésekre két műveletet határozunk meg. Az első, az Evaluate (Értékel), egy 
logikai kifejezést értékel ki, egy olyan környezetben, amely minden változóhoz igaz vagy 
hamis (true-false) értéket rendel. A második, a Replace (Cserél), egy változó kifejezésre 
való felcserélésével új logikai kifejezést állít elő. A Replace egyben azt is mutatja, hogy az 
Értelmező mintát nem csak kifejezések kiértékelésére használhatjuk; ebben az esetben pél- 
dául magának a kifejezésnek a kezelésére. 


Itt csak a BooleanExp, a VariableExp és az AndExp (LogikaiKif, VáltozóKif, ÉsKif) osz- 
tályokat mutatjuk be részletesen. Az OrExp és a NotExp (VagyKif, NemKif) hasonlóak az 
AndExp-hez, a Constant (Állandó) osztály a logikai állandókat ábrázolja. 


A BooleanExp határozza meg minden logikai kifejezést meghatározó osztály felületét: 


class BooleanExp ( 
public: 
BooleanExp( ) ; 


virtual "BooleanExp( ) ; 


virtual bool Evaluate(Contextg) - 0; 
virtual BooleanExp?" Replace(const chart, BooleanExp6) - 0; 
virtual BooleanExpt Copy() const - 0; 

$7 


A Context (Környezet) osztály a változók logikai értékekké alakítását határozza meg, amely 
értékeket a Ctt true és false állandóival ábrázoljuk. A Context felülete a következő: 





! Az egyszerűség kedvéért eltekintünk a műveletek kiértékelési sorrendjétől, és feltételezzük, hogy ez a szintaxis- 


fát felépítő objektum felelőssége. 
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class Context ( 
public: 
bool Lookup(const chart) const; 
void Assign(VariableExpr, bool); 
hb; 


A VariableExp egy nevesített változót ábrázol: 


class VariableExp : public BooleanExp ( 
public: 
VariableExp(const char"); 


virtual "VariáableExp(); 


virtual bool Evaluate(Context£) ; 
virtual BooleanExpY Replace(const chart, BooleanExpő6); 
virtual BooleanExpt Copy() const; 
private: 
chart name; 
); 


A konstruktor argumentumkérnt a változó nevét várja: 


VariableExp: : VariableExp (const char name) ( 
-name - strdup(name) ; 


) 


Egy adott változó kiértékelésének eredménye a változó értéke az aktuális környezetben. 


bool VariableExp::Evaluate (Contextg aContext) ( 
return aContext.Lookup(. name) ; 


yi 


A változó másolása egy új VariableExp-et eredményez: 


BooleanExp?! VariableExp::Copy () const ( 
return new VariableExp( name) ; 


2 


Ahhoz, hogy egy változót egy kifejezésre cserélhessünk, ellenőrizzük, hogy a változó neve 
megegyezik-e az argumentumként kapott névvel. 


BooleanExpYr VariableExp: :Replace ( 
const chart name, BooleanExpá exp 
T 1 
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Értelmező 
if (strcmp(name, name) -- 0) ( 
return exp.Copy(); 
) else ( 


return new VariableExp( name) ; 


) 


Az AndExp egy olyan kifejezést jelöl, amelyet két logikai kifejezés AND-del való összekap- 
csolásával állítunk elő. 


class AndExp : public BooleanExp ( 
public: 
AndExp (BooleanExpt, BooleanExpt;); 


virtual 7AndExp( ); 


virtual bool Evaluate(Context£) ; 
virtual BooleanExp" Replace(const char, BooleanExp6) ; 
virtual BooleanExp" Copy() const; 
private: 
BooleanExpt . operandi1; 
BooleanExp" . operand2; 
1; 


AndExp: : andExp (BooleanExptr opl, BooleanExpt op2) ( 
.operandi - opl; 
.operand2 - op2; 


Ha kiértékelünk egy AndExp-et, a tényezőket értékeljük, a visszakapott eredmény pedig 
a logikai , és" lesz. 


bool AndExp::Evaluate (Contextg aContext) ( 
return 
.operand1-sEvaluate(aContext) 66 
.operand2-sEvaluate (aContext) ; 


B 


Az AndExp a Copy (Másol) és Replace műveleteket a tényezőin ismételten végrehajtott 
hívásokkal valósítja meg: 


BooleanExpt AndExp::Copy () const ( 
return 
new AndExp(. operand1-5Copy() , . operand2-5Copy ( ) ; 


BooleanExp! AndExp::Replace (const char?t name, BooleanExpág exp) ( 
return 
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new AndExp( 
.operand1-5Replace(name, exp), f 
.operand2-5Replace(name, exp) 
); 
2 


Most már meghatározhatjuk a következő logikai kifejezést... 


(true and x) or (y and (not x)) 


..és kiértékelhetjük az x és y változókhoz rendelt true és false értékek egy adott esetében: 


BooleanExpt expression; 
Context context; 


VariableExpY x - new VariableExp("X") ; 
VariableExpt y - new VariableExp("Y") ; 


expression - new OrExp( 
new AndExp(new Constant(true), x), 
new AndExp(y, new NotExp(x)) 

); 


context.Assign(x, false); 
context.Assign(y, true); 


bool result - expression-sEvaluate(context) ; 


A kifejezés értéke az x és y ezen esetében true lesz. A változók más értékeinél is kiértékel- 
hetjük a kifejezést; ehhez egyszerűen csak meg kell változtatnunk a környezetet. 


Végezetül, az y változót egy új kifejezésre cserélhetjük, majd újra kiértékelhetjük: 


VariableExpt z - new VariableExp("Z"); 
NotExp not z(Z); 


BooleanExp?" replacement - expression-sReplace("Y", not z); 
context.Assigníz, true); 


result - replacement-sEvaluate(context) ; 


Ez a példa rámutat egy fontos dologra az Értelmező mintával kapcsolatban, mégpedig arra, 
hogy egy mondatot többféle művelet értelmezhet. A BooleanExp esetében meghatározott 
három művelet közül az Evaluate felel meg leginkább az arról alkotott elképzeléseink- 
nek, hogy egy értelmezőnek mit kell tennie — értelmeznie egy programot vagy kifejezést, 
majd visszaadni egy egyszerű eredményt. 


Értelmező 
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Ugyanakkor a Replace is tekinthető értelmezőnek, mégpedig olyannak, amelynek kör- 
nyezete a cserélendő változó neve, illetve a helyére lépő kifejezés, eredménye pedig egy új 
kifejezés. Még a Copy-ra is gondolhatunk úgy, mint egy üres környezetű értelmezőre. Fur- 
csának tűnhet persze, hogy e két műveletet értelmezőnek tekintjük, hiszen tulajdonképpen 
nem mások, mint fákon végzett alapműveletek. A Látogató tervezési minta példáinál majd 
bemutatjuk, miként lehet a három műveletet újraépítve önálló , értelmező látogató"-ba he- 
lyezni, ami bizonyítja hasonlóságuk nagy fokát. 


Az Értelmező minta nem csupán egy művelet, amelyet , szétosztunk" egy, az Összetétel 
mintát használó osztályhierarchiában. Az Evaluate-et azért tekintjük értelmezőnek, mert 
a BooleanExp osztályhierarchiára úgy gondolunk, mint ami egy nyelvet ábrázol. 


Ha adott egy hasonló osztályhierarchia, amely alkatrészeket ábrázol, nem valószínű, hogy 
az olyan műveleteket, mint a Weight vagy a Copy értelmezőnek tekintjük — bár ugyanúgy 
egy, az Összetétel mintát alkalmazó osztályhierarchiában kapnak helyet —, egyszerűen mert 
az alkatrészekre nem gondolunk nyelvként. Mindez persze nézőpont kérdése: ha közzé- 
tennék nyelvtanukat, a velük dolgozó műveletekre is úgy nézhetnénk, mint a nyelv értel- 
mezésének módszereire. 


Ismert felhasználások 


Az Értelmező mintát széles körben alkalmazzák az objektumközpontú nyelvek fordítóprog- 
ramjaiban, amilyen a Smalltalk is. A SPECTalk a minta segítségével a bemeneti fájlformátu- 
mok leírását értelmezi [Sza92], a OOCA megszorításfeloldó elemkészlet kötéseket vizsgál 
vele IHHMV92]. 


Ha legegyszerűbb formájára gondulunk (vagyis mint egy, az Összetétel mintán alapuló 
osztályhiererchiában elosztott műveletre), azt mondhatjuk, hogy az Összetétel minta szinte 


valamennyi alkalmazása tartalmazza az Értelmező mintát is, de használatát azokra az ese- 
tekre célszerű korlátozni, amikor az osztályhierarchia egy nyelvet ábrázol. 


Kapcsolódó minták 

Összetétel: az elvont szintaxisfa az Összetétel minta egy példája. 

Pehelysúlyú: megmutatja, hogyan oszthatók meg az elvont szintaxisfa terminálszimbólumai. 
Bejáró: az értelmező a szerkezet bejárásához felhasználhatja a Bejáró mintát. 


Látogató: arra használható, hogy egy osztályban tartsuk az elvont szintaxisfa egyes csomó- 
pontjainak viselkedését. 
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az, 
Bejáró 
Viselkedési objektumminta 
cél 


Az összetett objektumok elemeinek soros elérését a háttérben megbúvó ábrázolás felfedése 
nélkül biztosító módszer kialakítása. 


Egyéb nevek 


Iterator, Iterátor, Cursor (Kurzor, Sormutató) 


Feladat 


Az összesítő objektumoknak (aggregátumoknak), például a listáknak, módot kell adniuk 
arra, hogy elemeiket a belső szerkezet felfedése nélkül érhessük el. A listát emellett tud- 
nunk kell különböző módokon bejárni, attól függően, hogy mit szeretnénk véghezvinni. 
A Lista (LisD) felületet azonban valószínűleg nem akarjuk felduzzasztani különféle bejáró 
műveletekkel, még akkor sem, ha pontosan tudjuk, milyen műveletekre lesz szükségünk. 
Arra is szükség lehet, hogy ugyanazt a listát egyszerre több módon járjuk be. 


A Bejáró tervezési minta minderre módot ad. A minta kulcsa, hogy az elérés és bejárás fele- 
lősségi körét a lista objektumból egy bejáró (iterátor) objektumba helyezzük. A lista elemei- 
nek elérésére szolgáló felületet a Bejáró (Iterator) osztály határozza meg; az ebbe az osz- 
tályba tartozó objektumok tartják számon, melyik az aktuális elem, vagyis hogy mely ele- 
meket jártuk már be. 


Egy Lista osztály például a ListaBejárót (Listlterator) hívja meg, és az alábbi kapcsolatok áll- 
nak fenn köztük: 


Számlál) 
Hozzáfűz(Elem) 


Eltávolít(Elem) 








Bejáró 
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Mielőtt a ListaBejárót példányosíthatnánk, meg kell adnunk a bejárandó listát. Ha már ren- 
delkezünk ListaBejáró példánnyal, a lista elemeit sorban érhetjük el. Az AktuálisElem (Cur- 
rentltem) művelet a lista aktuális elemét adja vissza, az Első (First) az első elemet teszi aktu- 
ális elemmé, a Következő (Next) pedig a következőt; a Kész (IsDone) feladata annak ellen- 
őrzése, hogy túljutottunk-e már az utolsó elemen, vagyis hogy befejeztük-e a bejárást. 


A bejárás elválasztása a Lista objektumtól lehetővé teszi, hogy a különböző bejárási módok- 
hoz anélkül határozhassunk meg külön-külön bejárókat, hogy fel kellene sorolnunk azokat 
a Lista felületben. A SzűrőListaBejáró (FilteringListlterator) például csak azon elemekhez 
biztosítana hozzáférést, amelyek eleget tesznek bizonyos szűrési feltételeknek. 


Megfigyelhetjük, hogy a bejáró és a lista összekapcsolódik, az ügyfélnek pedig tudnia kell, 
hogy egy listát, és nem más összesítő szerkezetet (aggregátumot) jár be. Ebből következik, 
hogy az ügyfél egy bizonyos típusú aggregátumhoz kötődik. Jobb lenne, ha az aggregátum 
osztályát az ügyfél kódjának megváltoztatása nélkül módosíthatnánk — ebben segít a bejá- 
rók általánosítása a többalakú bejárás támogatásához. 


Példaként tegyük fel, hogy rendelkezünk egy UgróLista (SkipLis0) lista-megvalósítással is 
(az ugrólista (Pug90] olyan valószínűségi adatszerkezet, ami hasonlít a kiegyensúlyozott 
fákhoz), és mi olyan kódot szeretnénk írni, ami mind a Lista, mind az UgrólLista objektu- 
mok esetében működik. 


Először meghatározunk egy ElvontLista (AbstractList) nevű osztályt, ami a listák kezelésé- 
hez közös felületet biztosít. Szükségünk lesz egy elvont Bejáró (IteratoD) osztályra is, ami 
ugyanígy közös bejárási felületet ad. Ezután a különböző lista-megvalósításokhoz létrehoz- 
hatjuk a konkrét Bejáró alosztályokat. Mindennek eredménye a konkrét összesítő osztá- 
lyoktól független bejárás lesz. 







Elvonttista 


LétrehozBajáról) 
Számlál) 
Hozzáfűz(Elem) 
Eltávolít(Elem) 







ListaBejáró 
SE 











UgróListaBejáró 
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A kérdés azonban továbbra is az, hogyan hozzuk létre a bejárót. Mivel olyan kódot akarunk 
írni, ami független a konkrét Lista alosztályoktól, nem példányosíthatunk egyszerűen egy 
bizonyos osztályt. Ehelyett a lista objektumok felelősségi körébe utaljuk, hogy létrehozzák 
a nekik megfelelő bejárót. Ehhez egy LétrehozBejáró (Createlterator) vagy hasonló művelet 
szükséges, amelyen keresztül az ügyfelek egy bejáró objektumot igényelhetnek. 


A LétrehozBejáró a Gyártófüggvény mintára mutat példát; itt arra használjuk, hogy az ügy- 
fél a lista objektumtól a megfelelő bejárót kérhesse. A Gyártófüggvény alkalmazása két osz- 
tályhierarchiát eredményez; egyet a listák, egyet a bejárók számára, A LétrehozBejáró gyár- 
tófüggvény ezeket , köti össze". 


Alkalmazhatóság 
A Bejáró minta az alábbi esetekben alkalmazható: 
e El szeretnénk érni egy összesítő (aggregá0)) objektum tartalmát, anélkül, hogy annak 
belső ábrázolását felfednénk. 
e Több bejárási módot szeretnénk biztosítani összesítő objektumokhoz. 


e Egységes felületet szeretnénk adni a különböző összesítő szerkezetek bejárásához 
(vagyis támogatni szeretnénk a többalakú bejárást). 


Szerkezet 


Összesítő 





LétrehozBejárót) 





FAN 











Konkrétösszesítő 






KonkrétBejáró 





LétrehozBejáró() 





1 
1 
1 


retum new KonkrétBejáróíthis) ki 
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Résztvevők 
e Bejáró 
— Felületet határoz meg elemek elérésére és bejárására. 
s  KonkrétBejáró 
— Megvalósítja a Bejáró (Iterator) felületet. 
- Számon tartja, melyik elemnél tartunk az összesítő objektum bejárása során. 
e  Összesítő 
— Felületet határoz meg a Bejáró objektumok létrehozására. 
e  KonkrétÖsszesítő 
— Megvalósítja a Bejáró-létrehozó felületet a megfelelő KonkrétBejáró (Concrete- 
Iterator) példány visszaadásához. 


Együttműködés 


e A KonkrétBejáró számon tartja, melyik elemnél tartunk az összesítő objektum bejárá- 
sa során, és képes kiszámítani, melyik a következő bejárandó objektum. 


Következmények 


A Bejáró mintának három lényeges előnye van: 


1. Támogatja az összesítő objektumok bejárásának különböző változatait. Az összetett 
aggregátumok általában többféle módon is bejárhatók. A kód-előállítás vagy a jelentés- 
tani ellenőrzés például elemzőfák bejárását igényli. Az első esetében a bejárás előrefelé 
vagy balról jobbra (inorder) is történhet. A bejárók segítségével a bejárási algoritmus 
könnyen módosítható, csak ki kell cserélnünk a bejárópéldányt egy másikra; új bejárási 
módszerek támogatásához pedig elég, ha új Bejáró alosztályokat határozunk meg. 

2. A bejárók egyszerűbbé teszik az Összesítő felületet. A Bejáró bejárási felülete szük- 
ségtelenné teszi hasonló Összesítő felület létrehozását, így az összesítő felülete egy- 
szerűsödik. 

3. Az összesítőn egyszerre több bejárás lehet folyamatban. A bejárók számon tartják saját 
állapotukat (vagyis a bejárás állapotán), így egyszerre több bejárás is folyamatban lehet. 


Megvalósítás 


A Bejáró minta megvalósítására számos lehetőség kínálkozik; ezek közül az alábbiakban 
sorolunk fel néhányat. Előnyeik és hátrányaik többnyire az adott nyelv által biztosított ve- 
zérlési szerkezetektől függnek, egyes nyelvek (például a CLU ILG86D azonban közvetlenül 
támogatják ezt a tervezési mintát. 
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1. Ki vezérli a bejárást? Alapvető kérdés annak eldöntése, melyik fél vezérelje a bejá- 


rást: a bejáró vagy az azt használó ügyfél? Amikor az ügyfél a vezérlő, a bejárót külső 
bejárónak hívjuk, amikor a bejáró, belső bejárónak?. A külső bejárót alkalmazó ügyfe- 
leknek maguknak kell léptetniük a bejárást, és kifejezetten kérniük kell a következő 
elemet a bejárótól. A belső bejárónak ezzel szemben az ügyfél egy végrehajtandó 
műveletet ad át, amit az az összesítő minden elemére alkalmaz. 

A külső bejárók rugalmasabbak a belsőknél. Két gyűjtemény egyenlőségét példá- 
ul könnyen megvizsgálhatjuk egy külső bejáróval, míg ez belső bejáróval gyakor- 
latilag lehetetlen. A belső bejárók különösen az olyan nyelvekben gyengék, ame- 
lyek nem rendelkeznek névtelen függvényekkel, záradékokkal (closure, ilyen 
a Cst), vagy ,folytatásokkal" (continuations, ilyen a Smalltalk vagy a CLOS). Más- 
részről viszont a belső bejárók használata egyszerűbb, mert meghatározzák a be- 
járás logikáját. 


. Ki határozza meg a bejárási algoritmust? A bejáró nem az egyetlen hely, ahol a bejárá- 


si algoritmus meghatározható. Az összesítő meghatározhatja maga is, és a bejárót csu- 
pán arra használhatja, hogy a bejárás állapotát tárolja. A bejárók eme típusát kurzornak 
vagy sormutatónak hívjuk, miután feladata csak annyi, hogy az összesítő aktuális helyé- 
re mutasson. Az ügyfél meghívja a Következő (Next) műveletet az összesítőre a kurzor- 
ral mint argumentummal, a Következő pedig megváltoztatja a kurzor állapotát. 

Ha a bejárási algoritmusért a bejáró felel, könnyű ugyanazon az összesítőn különbö- 
ző bejárási algoritmusokat alkalmazni, és ugyanannak az algoritmusnak a használata 
különböző összesítőkön is egyszerűbb. Más részről a bejárási algoritmusnak szüksé- 
ge lehet arra, hogy elérje az összesítő privát változóit, mely esetben az algoritmusnak 
a bejáróba helyezése megsérti az összesítő egységbe zárását. 


. Mennyire ellenálló a bejáró? Az összesítő módosítása a bejárás közben veszélyes lehet. 


Ha ekkor elemeket adunk hozzá vagy veszünk el belőle, előfordulhat, hogy egy ele- 
met kétszer érünk el, vagy teljesen kihagyjuk. A legegyszerűbb megoldás, ha másola- 
tot készítünk az összesítőről, és a másolatot járjuk be, de ez általában túl költséges. 
Egy ellenálló bejáró biztosítja, hogy a hozzáadás és eltávolítás nem befolyásolja a bejá- 
rást, és ezt anélkül éri el, hogy másolatot készítene az összesítőről. Az ilyen bejárók 
megvalósítására számos mód kínálkozik. A legtöbbnek az az alapja, hogy a bejárót 
bejegyeztetjük az összesítő számára. Elem beszúrásakor vagy eltávolításakor az 
összesítő módosítja az általa alkalmazott bejárók belső állapotát, vagy a helyes bejá- 
rás biztosításához belsőleg tárolja a szükséges információt. 

Kofler IKof93] kitűnő leírást ad az ellenálló (robusztus) bejárók megvalósításáról az 
ET4--ban, míg Murray [Mur93] a megvalósítást a USL StandardComponents List osz- 
tályával kapcsolatban tárgyalja. 





? Booch aktív és passzív bejáróként hivatkozik rájuk [Boo94]. Ezek a fogalmak az ügyfél szerepére, és nem a bejá- 
ró aktivitásának fokára vonatkoznak. 


5 A kurzorok az Emlékeztető mintára adnak egyszerű példát, és megvalósításuk is sok szempontból hasonló. 
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4. További bejáró műveletek. A lehetséges legkisebb Bejáró felület az Első, Következő, 
Kész és AktuálisElem (First, Next, IsDone, Currentltem) műveletekből állf. Emellett 
azonban további műveletek is hasznosak lehetnek. A rendezett aggregátumok pél- 
dául rendelkezhetnek egy Előző (Previous) művelettel, ami a bejárót a megelőző 
elemre állítja. Egy Ugráslde (SkipTo) művelet a rendezett vagy sorszámozott (inde- 
xel0 gyűjtemények esetében jöhet jól. Egy ilyen művelettel a bejárót egy olyan ob- 
jektumra állíthatjuk, amely megfelel bizonyos követelményeknek. 

5. Többalakú bejárók használata a Ct44-ban. A többalakú bejáróknak megvan a ma- 
guk ára. Azt igénylik, hogy a bejáró objektumot egy gyártófüggvénnyel dinamikusan 
hozzuk létre. Emiatt használatukat célszerű azokra az esetekre korlátozni, amikor 
tényleg szükség van a többalakúságra. Más esetekben alkalmazzunk inkább konkrét 
bejárókat, amelyeket a verembe helyezhetünk. 

A többalakú bejáróknak van egy másik hátulütőjük is: törlésükért az ügyfél fele- 
lős. Az ilyen esetekben nagy a hibalehetőség, hiszen könnyen megfeledkezhe- 
tünk a kupacra helyezett bejáró objektum megsemmisítéséről, ha már nincs rá 
szükség. Ez különösen akkor valószínű, ha egy műveletben több kilépési pont 
van; ha valahol kivétel lép fel, a bejáró objektum által elfoglalt hely felszabadítá- 
sára soha nem kerül sor. 

Gyógyírt a Helyettes tervezési minta kínál. Ekkor a tényleges bejáró helyett egy 
veremfoglalású helyettest használunk, amely destruktorában törli a bejárót, így 
amikor a helyettes kikerül a hatókörből, vele együtt az ,igazi" bejáró is megsem- 
misül. A helyettes megfelelő takarítást biztosít, még kivételek fellépése esetén is. 
A megoldás nem más, mint a jól ismert Ct-elv, ,az erőforrás-foglalás egyben elő- 
készítés (inicializálás)" [(ES90] alkalmazása. További részleteket a Példakód rész- 
ben láthatunk. 

6. A bejárók kivételezett hozzáféréssel rendelkezhetnek. A bejárókra úgy is tekinthe- 

tünk, mint az őket létrehozó összesítők bővítéseire. A bejáró és az összesítő szoros 
csatolásban állnak egymással; ezt a kapcsolatot a Ct--ban például úgy fejezhetjük 
ki, ha a bejárót összesítője , barátjává" (friend) tesszük. Ekkor az összesítőben nem 
kell olyan műveleteket meghatároznunk, amelyek egyetlen célja, hogy lehetővé te- 
gyék a bejárók számára a bejárás hatékony megvalósítását. 
Mindazonáltal az ilyen kivételezett hozzáférés az új bejárási módok megadását meg- 
nehezíti, mert az új barát hozzáadása az összesítő felületének módosítását igényli. 
Ennek elkerülésére a Bejáró osztály védett (protected) műveleteket tartalmazhat, 
melyeken keresztül az összesítő fontos, de nyilvánosan nem elérhető tagjaihoz fér- 
hetünk hozzá. A Bejáró alosztályai (és kizárólag azok) ezekkel a védett műveletek- 
kel nyerhetnek kivételezett hozzáférést az összesítő objektumhoz. 





§ A felületet még kisebbé tehetjük, ha a Következő, Kész és AktuálisElem műveleteket egyetlen műveletben egye- 
sítjük, amely a következő objektumra lép és visszaadja azt. Ha a bejárás befejeződött, a művelet egy különleges 
értékkel tér vissza (például 0-val), ami a bejárás végét jelzi. 
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7. Bejárók összetételek számára. A külső bejárók megvalósítása az olyan önhívó össze- 
sítő szerkezetek (rekurzív aggregátumok) esetében, mint amilyeneket az Összetétel 
mintában találhatunk, nehéz lehet, mert a szerkezet egy adott pozíciója a beágyazott 
aggregátumok számos szintjét átfoghatja. Ekkor a külső bejárónak tárolnia kell az 
összetételen keresztül vezető útvonalat, hogy megállapíthassa, melyik az aktuális 
objektum. Ennél sokszor egyszerűbb egy belső bejáró használata, ami az aktuális he- 
lyet egyszerűen önmaga ismételt meghívásával képes rögzíteni, s így egyben tárolni 
az útvonalat a hívási veremben. 

Ha az adott összetétel csomópontjai rendelkeznek egy felülettel, ami a testvérekre, 
szülőkre vagy gyermekekre ugrást szolgálja, egy kurzor alapú bejáró jobb megoldás 
lehet. A kurzornak csak az aktuális csomópontot kell számon tartania, az összetétel 
bejárásához támaszkodhat az említett felületre. 

Az összetételeket gyakran többféleképpen szükséges bejárni. A leggyakoribb az elő- 
re haladó, a visszafelé haladó, a balról jobbra haladó (inorder) és a szélességi bejárás 
(horizontális bejárás, breadth-first). Ezeket külön bejáró osztályokkal támogathatjuk. 

8. Null bejárók. A NullBejáró olyan csökevényes bejáró, amely a korlátfeltételek kezelé- 

sénél jöhet jól. Meghatározása szerint a Nulllterator mindig végzett a bejárással, va- 
gyis Kész (IsDone) művelete mindig true-ra értékelődik ki. 
A NullBejáró a faszerkezetű aggregátumok (amilyenek az Összetételek is) bejárását 
teheti könnyebbé. A bejárás minden pontján elkérjük az aktuális elem gyermekeit; 
az összesítő elemek a szokott módon egy konkrét bejárót adnak vissza, a levélele- 
mek azonban egy NullBejáró példányt. Ezzel a megoldással a teljes szerkezetet egy- 
ségesen járhatjuk be. 


Példakód 


Egy egyszerű Lista osztály (List) megvalósítását fogjuk megnézni, amely része az alap- 
könyvtárunknak (lásd a C függeléket). Két Bejáró-megvalósítást mutatunk be: egyet a lista 
előre haladó bejárásához, egyet pedig a visszafelé haladáshoz. (Az alapkönyvtár csak az el- 
sőt támogatja.) Ezután megmutatjuk, hogyan kell használni ezeket a bejárókat, és hogyan 
kerülhetjük el, hogy egy adott megvalósításhoz kötődjünk. Ezt követően némi módosítást 
hajtunk végre, hogy gondoskodhassunk a bejárók megfelelő törléséről. Az utolsó példa egy 
belső bejárót mutat be, és összehasonlítja azt külső megfelelőjével. 


1. A List és Iterator felületek. Először tekintsük meg a List felületnek azt a részét, ame- 
lyik a bejárók megvalósítása szempontjából lényeges. A teljes felületet a C függelék- 
ben találhatjuk meg. 

template cclass Items 
class List ( 
public: 
List(long size - DEFAULT LIST CAPACITY) ; 


long Count() const; 


NNNKEKEES ES ESZE 
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Items Get(long index) const; 
/ A 9ETESS 
); 


A List osztály nyilvános felületén keresztül meglehetősen hatékony módot ad a bejá- 
rás támogatására; mindkét típusú bejárás megvalósításához megfelel. Így nincs szük- 
ség arra, hogy a bejáróknak kivételezett hozzáférést adjunk a háttérben megbúvó adat- 
szerkezethez, vagyis a bejáró osztályok nem barátjai (friend) a List osztálynak. 
A különböző bejárások észrevétlen használatát úgy támogatjuk, hogy létrehozunk egy 
elvont Iterator osztályt, amely meghatározza a bejáró felületet. 
template cclass Item: 
class Iterator ( 
public: 
virtual void First() - 0; 
virtual void Next() - 0; 
virtual bool IsDone() const - 0; 
virtual Item CurrentItem() const - 0; 
protected: 
Iterator() ; 
1; 
2. Az Iterator alosztályainak megvalósítása. A ListIterator (CistaBejáró) az Ite- 
rator alosztálya. 
template cclass Item: 
class Listlterator : public Iteratorcitem; ( 
public: 
ListIlterator(const ListcItemsY aList); 
virtual void First(); 
virtual void Next(); 
virtual bool IsDone() const; 
virtual Item CurrentIltem() const; 


private: 
const ListcItemst list; 
long . current; 

HA 


A ListIterator megvalósítása egyszerű. A List-eta current indexszel együtt 
tárolja: 
template cclass Items 
ListIlteratorcitems:: Listlterator ( 
const ListcItemost aList 
) :  list(aList) , -eurrent(0) ( 
) 


A First (Első) az első elemre állítja a bejárót: 
template cclass Item: 
void Listlteratorcitem;: :First () ( 
. current 5 0; 


) 
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A Next (Következő) a következő elemre léptet: 
template cclass Items 
void ListlteratorcItem:: :Next () ( 
—-currenttir; 


1 


Az IsDone (Kész) ellenőrzi, hogy az index a listán belüli elemre hivatkozik-e: 
template cclass Items 
void ListlteratorcItems: : IIsDone () const ( 
return . current 5-  list-5Countt-(() ; 


Új 


Végül a Current Item (AktuálisElem) az aktuális index által jelzett helyen levő ele- 
met adja vissza. Ha a bejárás már befejeződött, IteratoroutofBounás kivételt 
váltunk ki: 
template cclass Item: 
Item ListIteratorcItem; : : CurrentItem () const ( 
if (IsDone()) ( 
throw IteratorOutOfBounds; 
§ 
return list-sGet (current) ; 


§. 


A visszafelé haladó ReverseListIterator megvalósítása ugyanilyen, de annak 
First műveletea current indexet a lista végére állítja, a Next pedig az első elem 
irányába csökkentia current értékét. 

3. A bejárók használata. Tételezzük fel, hogy van egy listánk, amely Employee (Alkal- 
mazott) objektumokat tartalmaz, és az összes alkalmazottat ki szeretnénk íratni. Ezt az 
Employee osztály a Print (Kiír) művelettel támogatja. A lista kiírásához a Print - 
Employees (KiírAlkalmazottak) műveletet határozzuk meg, amelynek argumentuma 
egy bejáró, amellyel a művelet bejárja és kiírja a listát. 

void PrintEmployees (IteratorcEmployeets6§ i) ( 
for (i.First(); !i.IsDone(); i.Next()) ( 
i.CurrentItem( ) -sPrint () ; 


) 
T 


Mivel mind előre haladó, mind visszafelé haladó bejáróval rendelkezünk, a fenti mű- 
velet újrahasznosításával mindkét sorrendben kiírathatjuk az alkalmazottakat. 
ListcEmployeetst employees; 
BE ss 
ListIlteratorcEmployeets forward(employees) ; 
ReverseListílteratorcEmployeets backward (employees) ; 


PrintEmployees (forward) ; 
PrintEmployees (backward) ; 
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4. Egy adott lista-megvalósításhoz való kötődés elkerülése. Vizsgáljuk meg, hogyan érinte- 
né bejáró kódunkat, ha a List-et ugrólistaként valósítanánk meg. A List SkipList 
alosztályának biztosítania kell egy SkipListIterator-t (UgrólListaBejáró), amely 
megvalósítja az Iterator felületet. A SkipListIterator-nak a bejárás hatékony 
végrehajtásához nem elég csupán egy indexet fenntartania, de mivel az osztály megfe- 
lel az Iterator felületnek, a PrintEmployees művelet akkor is használható, ha az 
alkalmazottakat egy SkipList objektumban tároljuk. 

SkipListcEmployeet:t employees; 
12 


SkipListIteratorcEmployeets iterator (employees) ; 
PrintEmployees (iterator) ; 


Bár ez a megközelítés működik, jobb lenne, ha nem kötődnénk egy bizonyos List- 
megvalósításhoz (ebben az esetben konkrétan a SkipList-hez). Bevezethetnénk 
egy AbstractList (Elvontlista) nevű elvont osztályt, amellyel szabványosíthatjuk 
a listafelületet a különböző lista-megvalósításokhoz. Ekkor a List és a SkipList 
az AbstractList alosztályai lennének. 
A többalakú bejárás lehetővé tételéhez az AbstractList a Createlterator 
(LétrehozBejáró) gyártófüggvényt határozhatja meg, amit az alosztályok felülírnak, 
hogy visszaadják a megfelelő bejárót: 
templatecclass Item: 
class AbstractList ( 
public: 
virtual IteratorcItemst Createlterator() const - 0; 
Wass 
L; 


Egy másik lehetőség, hogy egy általános mixin osztályt határozunk meg Traver- 
sable (Bejárható) néven, ami a bejárók létrehozásának felületét írja le. Az összesítő 
osztályok így a Traversable , bekeverésével" támogathatják a többalakú bejárást. 
A List a Createlterator felülbírálásával egy ListIterator objektumot ad 
vissza: 

templatecclass Item: 

IteratorcItemst ListcItems;5::Createlterator() const ( 

return new ListlteratorciItems (this) ; 


) 


Most már abban a helyzetben vagyunk, hogy konkrét megvalósítástól független kó- 
dot írhatunk az alkalmazottak listájának kiíratására. 
// csak azt tudjuk, hogy van egy AbstractList-ünk 
AbstractList-cEmployeers5t employees; 
E vnváérák 


IteratorcEmployeet:5t iterator - employees-5Createlterator ( ) ; 
PrintEmployees (titerator) ; 
delete iterator; 
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5. A bejárók törlésének biztosítása. Figyeljük meg, hogy a CreateIterator egy újon- 


nan létrehozott bejáró objektumot ad vissza, melynek törléséért mi felelünk. Ha elfe- 
lejtjük, memóriaszivárgást idézhetünk elő. Az ügyfelek dolgát megkönnyítendő biz- 
tosítunk egy IteratorPtr (BejáróMutató) nevű mutatót, ami bejáróhelyettesként 
viselkedik, és gondoskodik az Iterator objektum megsemmisítéséről, ha arra 
nincs többé szükség. 
Az IteratorPtr-nek mindig a veremben foglalunk helyet. A C--4- automatikusan 
meghívja majd a destruktorát, amely törli magát a bejárót. Az IteratorPtr túlter- 
heli mind az operator-5, mind az operator" műveleteket, így pontosan egy be- 
járót címző mutatóként kezelhető. Az IteratorPtr tagjainak megvalósítása hely- 
ben kifejtett (inline), így nem okoznak többletterhet. 
templatecclass Item: 
class IteratorPtr ( 
public: 
IteratorPtr(Iteratorcitemst i): i(i) ( ) 
"IteratorPtr() ( delete i;) 
IteratorcItem:5t operator-—5() (í( return i; ) 
Iteratorcitems§ operatort() ( return " i; ) 
private: 


// a másolás és hozzárendelés tiltása, hogy 
// elkerüljük az  i többszöri törlését 


IteratorPtr(const IteratorPtr6); 
IteratorPtr§g operator-(const IteratorPtreé); 
private: 
Iteratorcitemst i; 
tag 


Az Iteratorbptr lehetővé teszi, hogy egyszerűsíthessük a kiíró kódot: 


AbstractListcEmployeetst employees; 
ÚV esz 


IteratorPtrcEmployeets5 iterator (employees-sCreatelteratotr ( ) ) ; 
PrintEmployees(titerator) ; 


Egy belső listabejáró. Utolsó példaként nézzük meg egy belső vagy passzív List- 
Iterator osztály egy lehetséges megvalósítását. Itt a bejáró vezérli a bejárást, és 
minden elemen végrehajt egy műveletet. 

A kérdés ebben az esetben az, hogyan adjuk át a bejárónak paraméterként az eleme- 
ken végrehajtandó műveleteket. A C-t nem támogatja a névtelen függvényeket vagy 
záradékokat (closure), amelyek más nyelvekben e feladatra rendelkezésre állnak. 
Legalább két lehetőségünk azért akad: (1) egy függvényre hivatkozó (globális vagy 
statikus) mutatóban átadni az információt, vagy (2) alosztályokra támaszkodni. 





5 Ezt fordításkor egyszerűen biztosíthatjuk, ha privát new (új) és delete (töröl) műveleteket vezetünk be. Meg- 
valósítás nem szükséges hozzájuk. 
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Az első esetben a bejáró minden elemnél meghívja a számára átadott műveletet, 
a másodikban egyetlen műveletet hív meg, amelyet a megfelelő viselkedés biztosítá- 
sa érdekében az alosztályok felülbírálnak. 
Egyik megoldás sem tökéletes. A bejárás közben gyakran szükség lehet az állapot nyo- 
mon követésére, a függvények pedig nem igazán alkalmasak erre; az állapotot statikus 
változókkal kellene számon tartanunk. Egy Iterator alosztályban kényelmesen el- 
helyezhetjük az állapotinformációt, mondjuk egy példányváltozóban, de a különböző 
bejárásokhoz külön-külön alosztályt létrehozni rengeteg munkát igényel. 
Íme a második, alosztályokat használó megoldás vázlata. A belső bejáró neve itt List - 
Traverser 
templatecclass Item: 
class ListTraverser ( 
public: 
ListTraverser(ListcItemst aList); 
bool Traverse(); 
protected: 
virtual bool ProcessItem(const Itemg) - 0; 
private: 
ListlteratorcItems; , iterator; 
1; 
A ListTraverser paraméterként egy List példányt kap, és egy külső List- 
Iterator segítségével hajtja végre a bejárást. A Traverse elkezdi a bejárást, és 
minden elemre meghívja a ProcessItem (FeldolgozElem) műveletet. A belső bejá- 
ró a bejárást azzal fejezheti be, hogy false értéket ad vissza a ProcessItem-ből. 
A Traverse tájékoztat, ha a bejárás idő előtt befejeződött. 
templatecclass Items 
ListTraversercItem:: :ListTraverser ( 
ListciItems$t aList 
) :  iterator(aList) ( ) 


templatecclass Items 
bool ListTraversercIitem;: : Traverse () ( 
bool result - false; 


for 1 
.-iterator.First(); 
! iterator.IsDone() ; 
.iterator.Next() 
74 
result - ProcessIltem( iterator.Currentltem-( ) ) ; 


if (result -- false) ( 
break; 


9 


return result; 
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A ListTraverser segítségével írassuk ki az első tíz alkalmazottot a listából. Ehhez 
alosztályokat kell származtatnunk a ListTraverser-ből, és felül kell bírálnuk 
a ProcessItem műveletet. A kiírt alkalmazottak számáta count példányváltozó- 
ban számláljuk meg. 
class PrintNEmployees : public ListTraversercEmployeets ( 
public: 
PrintNEmployees(List-cEmployeetsr aList, int n) 
ListTraversercEmployeet5(aList), 
-totalíln),  countt0) ( ) 


protected: 

bool ProcessItem(Employeet constf£); 
private: 

int total; 


int . count; 


1 


bool PrintNEmployees: :ProcessItem (Employeet constő e) ( 
.Countt4; 
e-sPrint(); 
return ,. count c total; 

) 

A PrintNEmployees az alábbi módon írja ki az első tíz alkalmazott nevét: 
ListcEmployeets5t employees; 
its 


PrintNEmployees pa(employees, 10); 
pa.Traverse( ) ; 


Megfigyelhetjük, hogy az ügyfél nem határozza meg a bejárási ciklust; a teljes bejárá- 
si logika újrahasznosítható. Ez a belső bejárók legfontosabb haszna. Kicsit több 
munkát igényel ugyan, mint a külső bejárók használata, mert meg kell határoznunk 
egy új osztályt. Vessük össze ezt egy külső bejáró alkalmazásával: 
ListIlteratorcEmployeets5 i(employees) ; 
iüt. G0üHE a Dy 


for (i.First(); !i.IsDone(); i.Next()) ( 
counttt; 
i.CurrentItem() -sPrint() ; 


if ieount sz 19) 4 
break; 


) 


A belső bejárók többféle bejárást zárhatnak egységbe. FilteringListTraverser 
(SzűrőListaBejáró) néven például egy olyan bejárást adhatunk meg, amely csak azo- 
kat az elemeket dolgozza fel, amelyek megfelelnek bizonyos követelményeknek: 
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templatecclass Items 
class FilteringListTraverser ( 
public: 
FilteringListTraverser(ListcItemst aList); 
bool Traverse() ; 
protected: 
virtual bool ProcessItem(const Itemg) - 0; 
virtual bool TestItem(const Items) - 0; 
private: 
ListlteratorcItems .  iterator; 
); 
Ez a felület megegyezik a ListTraverser-ével, azzal a különbséggel, hogy hozzá- 
adtuk a követelményeket ellenőrző TestItem (TesztelElem) tagfüggvényt. Az al- 
osztályok ennek felülbírálásával hajtják végre az ellenőrzést. 
A Traverse az ellenőrzés eredményének függvényében dönti el, hogy folytatja-e 
a bejárást: 
templatecclass Items 


void FilteringListTraversercItem; : : Traverse() ( 
bool result - false; 


for ( 
—-iterator.First(); 
! iterator.IsDone ( ) ; 
—-iterator.Next() 

9 § 


if (TestIltem( iterator.CurrentIltem())) ( 
result - ProcessItem( iterator.CurrentIitem-( ) ) ; 
if (result -- false) ( 
break; 


) 
return result; 


) 


A fenti osztály egy másik változatában úgy is meghatározhatnánk a Traverse mű- 
veletet, hogy már akkor is eredményt adjon, ha legalább egy elem teljesíti a köve- 
telményeket." 





§ A Traverse művelet ezekben a példákban Sablonfüggvény, melynek alapműveletei a TestItem és 
a ProcessItem 
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Ismert felhasználások 


A bejárók hétköznapinak számítanak az objektumközpontú rendszerekben; a legtöbb gyűj- 
teményosztály-könyvtár kínál bejárókat valamilyen formában. 


íme egy példa erre a Booch komponensek közül [Boo94], amely egy népszerű gyűjtemény- 
osztály-könyvtár. A könyvtárban megtalálható a sor (gueue) rögzített méretű (korlátos) és 
dinamikusan növekvő (nem korlátos) megvalósítása is. Felületét az elvont Oueue osztály 
írja le. A különböző megvalósításokhoz a könyvtár úgy biztosítja a többalakú bejárást, hogy 
a sorbejárót az elvont Oueue osztályfelületre alapozva valósítja meg. Ennek az az előnye, 
hogy nincs szükség gyártófüggvényre, ami a sor-megvalósításoktól elkéri a megfelelő bejá- 
rót. Természetesen az elvont Oueue osztály felületének elegendő szolgáltatást kell biztosí- 
tania ahhoz, hogy a bejárót hatékonyan megvalósíthassuk. 


A Smalltalk nem igényli a bejárók kifejezett meghatározását. A szabványos gyűjteményosz- 
tályok (Bag, Set, Dictionary, OrderedCollection, String stb.) mind meghatároznak egy belső 
bejáró metódust (do:), amely argumentumként egy blokkot (vagyis záradékob) kap. 
A gyűjtemény minden eleme kapcsolódik a blokkban levő helyi változóhoz, majd a blokk 
végrehajtódik. A Smalltalk emellett Stream (Folyam) osztályokat is tartalmaz, amelyek tá- 
mogatnak egy, a bejárókhoz hasonló felületet. A ReadStream (OlvasFolyam) lényegében 
véve egy bejáró, és minden soros elérésű gyűjtemény külső bejárójaként alkalmazható. 
A nem soros elérésű gyűjtemények (pl. Set, Dictionary) számára nem áll rendelkezésre 
szabványos külső bejáró. 


A korábban leírt takarító helyettest és többalakú bejárókat az ETt--- tároló osztályai biztosít- 
ják IVGM881. A Unidraw grafikus szerkesztő keretrendszeri osztályai kurzor alapú bejáró- 
kat használnak ÍVL90]. 


Az ObjectWindows 2.0 [Bor94] bejárók egész osztályhierarchiáját kínálja a tárolókhoz; se- 
gítségükkel a különböző tárolótípusok ugyanúgy járhatók be. A bejárás itt az utótagos nö- 
velő művelet (---) túlterhelésén alapul, amely előre lépteti a bejárót. 


Kapcsolódó minták 


Összetétel: Bejárókat gyakran alkalmazunk az olyan önhívó szerkezetek esetében, mint az 
Összetételek. 


Gyártófüggvény: A többalakú bejárók a megfelelő Bejáró alosztályok példányosításához 
gyártófüggvényekre támaszkodnak. 


Emlékeztető: Gyakran alkalmazzák együtt a Bejáró mintával. A bejárók belsőleg tárolt ,em- 
lékeztetők" segítségével rögzíthetik a bejárás állapotát. 





Közvetítő 


277 





Közvetítő 


Viselkedési objektumminta 


Egyéb nevek 

Mediator 

cél 

A cél meghatározni egy objektumot, amely objektumok egy halmazának együttműködését 
irányítja. (Vagyis ezeket egyetlen objektumba tokozzuk be.) A módszerrel laza csatolást ho- 


zunk létre, amelyben az egyes objektumok közvetlenül nem hivatkozhatnak egymásra, 
a köztük levő kapcsolatok pedig egymástól függetlenül módosíthatók. 


Feladat 


Az objektumközpontúság arra ösztönöz, hogy a kívánt viselkedést objektumok között 
osszuk szét. A viselkedés elosztása viszont olyan objektumszerkezetet eredményezhet, 
amelyben az objektumok között számtalan kapcsolat létezik — a legrosszabb esetben min- 
den objektum tudni fog minden objektumról. Bár egy rendszer több objektumra való fel- 
osztása általában növeli az újrahasznosíthatóságot, a kapcsolatok szövevénye csökkenti 
azt. Ha egy objektum számos másikkal áll bonyolult kapcsolatban, valószínűbb, hogy azok 
segítsége nélkül nem képes ellátni a feladatát, így a rendszer ,tömbszerűen? viselkedik. Sőt, 
a rendszer működésének jelentősebb megváltoztatása is nehezebbé válik, hiszen a viselke- 
dést számos objektum között osztottuk szét, így arra kényszerülhetünk, hogy a rendszer 
működésének testreszabásához sok-sok alosztályt kelljen létrehoznunk. 


Példaként vegyük a párbeszédablakok megvalósítását egy grafikus felhasználói felületen. 
A párbeszédablak az alábbi ábrán bemutatotthoz hasonló módon egy ablak segítségével kí- 
nál fel számos grafikus vezérlőelemet, például gombokat, menüket vagy beviteli mezőket: 


DEBEKSESETKNÉÁN TT KNNATK 
. The guick brown fox... ; 








! Waght Omedium ebold 
(Slant Oroman Gitalic 


Size [34 pt (9) [Jcondensed 
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Az ablak vezérlői között gyakran függőségek állnak fenn, például valamelyik gombot le kell 
tiltanunk, ha egy adott beviteli mező üres, vagy meg kell változtatnunk a mező tartalmát, ha 
a felhasználó kiválaszt egy elemet egy listamezőből. Ezek fordítottja is előfordulhat, vagyis 
a mezőbe írás is automatikusan kiválthatja a megfelelő elem vagy elemek kijelölését a lista- 
mezőben, illetve egyes gombok elérhetővé válhatnak, hogy a felhasználó számára lehetővé 
tegyék, hogy felhasználhassa a beírt szöveget, mondjuk módosítsa vagy törölje azt a dolgot, 
amire a szöveg hivatkozik. 


A különböző párbeszédablakokban a vezérlők között különféle kapcsolatok állhatnak fenn. 
Így bár ezek az ablakok általában hasonló elemeket tartalmaznak, nem használhatják fel au- 
tomatikusan a vezérlőosztályokat; előbb azok testreszabására van szükség, hogy tükrözzék 
az adott párbeszédablakban fennálló függőségeket. Az alosztályok létrehozásával történő 
egyedi testreszabás mindazonáltal kimerítő lehet, hiszen rengeteg osztályról van szó, 


Mindeme problémákat úgy kerülhetjük el, ha a közös viselkedést egy önálló közvetítő objek- 
tumba zárjuk. A közvetítő feladata, hogy vezérelje és összehangolja objektumok egy cso- 
portjának együttműködését. A közvetítő olyan köztes rétegként szolgál, amely megakadá- 
lyozza, hogy a csoport objektumai közvetlenül hivatkozzanak egymásra. Az objektumok 
csak a közvetítőt ismerik, így a keresztkapcsolatok száma jelentősen lecsökken. 


Például létrehozunk egy közvetítőt BetűtípusPárbeszédablaklrányító (FontDialogDirector) né- 
ven, amely egy betűtípus-választó párbeszédablak vezérlőit hangolja össze. A FontDialog- 
Director ismeri valamennyi vezérlőt, így kommunikációs elosztóként viselkedik a vezérlők 


számára: 
egylistalMező 
irányító 













egyÜgyfél 





irányító 






irányító e 
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Az alábbi együttműködési diagram azt illusztrálja, hogyan működnek együtt az objektu- 


mok, ha a listamezőben kijelölt elem módosul: 
































Közvetítő Kollégák 
egyÜgyfél —  egyBetűtípusPárbeszédablaklrányító  egyListalMező egyBevitelilMező 
[/ MutatPárbeszédablak() 

[F———— mi 
VezérlőMegváltozottt) 1] 
fless ezet 
Szerezkijelölés() 
BeállítSzöveg() ] 








my 





Íme az események sorrendje, melyek során a listamezőben kijelölt elem átadódik a beviteli 


mezőnek: 





. A listamező közli az irányítóval (director), hogy megváltozott. 


2. Az irányító elkéri a kijelölt elemet a listától. 

3. Az irányító átadja a kijelölt elemet a beviteli mezőnek. 

4. Most, hogy a beviteli mező szöveget tartalmaz, az irányító elérhetővé teszi a művele- 
tek kezdeményezésére (, félkövér", , dőlt") szolgáló gombokat. 


Figyeljük meg, hogyan közvetít az irányító a lista és a beviteli mező között. A vezérlők egy- 
mással nem társalognak közvetlenül, csak közvetetten, az irányítón keresztül. Nem kell 
tudniuk egymásról, csak az irányítót kell ismerniük. Továbbá, mivel a viselkedést egyetlen 
osztály tartalmazza, az eme egyetlen osztály bővítésével vagy kicserélésével módosítható. 


Az alábbi ábrán azt láthatjuk, hogyan építhető be a BetűtípusPárbeszédablaklrányító elvont 
szerkezete egy osztálykönyvtárba: 














Párbeszédablaklrányító la berakás 
MutatPárbeszédablak() 
LétrehozvVezérlők() 
VezérlőMegváltozottíVezérlő) 








p) o4---- irányító-5 VezérlőMegváltozottíthis) 














BetűtípusPárb.ablaklrányító 


Létrehozvezértők() 
VezérlőMegváltozott(Vezérlő) 
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A Párbeszédablaklrányító (DialogDirector) egy elvont osztály, amely a párbeszédablakok 
általános viselkedését írja le. Az ügyfelek a MutatPárbeszédablak (ShowDialog) művelet 
meghívásával megjeleníthetik az ablakot a képernyőn. A Létrehozvezérlők (CreateWidgets) 
elvont művelet az ablak vezérlőinek létrehozására szolgál. A VezérlőMegváltozott (Widget- 
Changed) egy másik elvont művelet, amelyet a vezérlők akkor hívnak meg, amikor tájékoz- 
tatni akarják az irányítót, hogy állapotuk megváltozott. A Párbeszédablaklrányító alosztá- 
lyai a LétrehozVezérlők felülírásával hozzák létre a megfelelő vezérlőket, a változások ke- 
zeléséhez pedig a VezérlőMegváltozott műveletet bírálják felül. 


Alkalmazhatóság 


A Közvetítő minta alkalmazása a következő esetekben célszerű: 


s Objektumok egy halmaza jól meghatározott, de bonyolult módon kommunikál egy- 
mással. Az előálló kölcsönös függőségek szerkezete esetleges és nehezen átlátható, 

e Egy objektum újrahasznosítása nehéz, mert számos más objektumra hivatkozik, illet- 
ve számos más objektummal tart kapcsolatot. 

e Több osztály között elosztott viselkedést kellene alosztályok sokasága nélkül 
testreszabnunk. 


Szerkezet 


Közvetítő -a- Kolléga 


Konkrétközvetítő [—— — .]. Konkrétkollégat dt Konkrétkolléga2 





















































Egy jellegzetes objektumszerkezet így nézhet ki: 












egyKolléga 
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Résztvevők 


Közvetítő (Párbeszédablaklrányító) 

— Felületet határoz meg a Kolléga (Colleague) objektummal való kapcsolattartáshoz. 

Konkrétközvetítő (BetűtípusPárbeszédablaklrányító) 

-— A Kolléga objektumok összehangolásával kialakítja az együttműködést. 

— Ismeri kollégáit és gondoskodik róluk. 

Kolléga osztályok (ListaMező, BeviteliMező) 

- Minden Kolléga osztály ismeri a Közvetítő (Mediator) objektumát. 

- A kollégák minden olyan esetben a közvetítőhöz fordulnak, amikor egy másik 
kollégával szeretnének kommunikálni. 


Együttműködés 


A kollégák kérelmeket küldenek a Közvetítő objektumoknak és kérelmeket fogad- 
nak onnan. Az együttműködést a közvetítő alakítja ki azzal, hogy továbbítja a kérel- 
meket a megfelelő kollégá(k)nak. 


Következmények 


A Közvetítő tervezési minta előnyei és hátrányai a következők: 


8 


Csökkenti az alosztályok számát. A közvetítő egy helyre gyűjt egy olyan viselkedést, 
amit másképp több objektum között kellene elosztani. A viselkedés megváltoztatá- 
sához így csak a Közvetítő osztályból kell alosztályokat származtatnunk, a Kolléga 
osztályok eredeti formájukban újrahasznosíthatók. 

Elválasztja a kollégákat. A közvetítő laza csatolást hoz létre 4 kollégák között. A Kol- 
léga és Közvetítő osztályok egymástól függetlenül variálhatók és újrahasznosíthatók. 
Egyszerűsíti az objektumprotokollokat. A közvetítő a sok-sok kapcsolatokat a köz- 
vetítő és kollégái egy-sok kapcsolataival helyettesíti. Az egy-sok kapcsolatok 
könnyebben átláthatók, illetve könnyebb fenntartani és bővíteni azokat. 

Az objektumok együttműködését elvonttá teszi. A közvetítés mint külön fogalom 
önálló objektumba zárása lehetővé teszi, hogy figyelmünket az objektumok együtt- 
működésének módjára összpontosíthassuk, és ne kelljen foglalkoznunk egyedi vi- 
selkedésükkel. Így a rendszer objektumainak együttműködése tisztábban átlátható. 
Központosítja a vezérlést. A Közvetítő minta az együttműködés egyszerűsítéséért a köz- 
vetítő összetettségével fizet. Miután a közvetítő tartalmazza a protokollokat, bonyolul- 
tabb lehet, mint bármelyik kolléga, és nehezen kezelhetővé, tömbszerűvé válhat. 
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Megvalósítás 


A Közvetítő minta megvalósítása során a következőkre kell figyelni: 
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Az elvont Közvetítő osztály kihagyása. Ha a kollégák csak egyetlen közvetítővel áll- 
nak kapcsolatban, nincs szükség elvont Közvetítő osztály létrehozására. A Közvetítő 
által biztosított elvont csatolás lehetővé teszi a kollégáknak, hogy különböző Közve- 
títő alosztályokkal működjenek együtt, és ez megfordítva is igaz. 

Kapcsolattartás a Kolléga és Közvetítő osztályok között. A kollégáknak kapcsolatba 
kell lépniük közvetítőjükkel, ha valamilyen számukra fontos esemény történik. 
A közvetítőt megvalósíthatjuk például megfigyelőként, a Megfigyelő tervezési minta 
alkalmazásával. A kollégák ebben az esetben Alanyok (Subject), amelyek állapotuk 
megváltozásakor értesítést küldenek a közvetítőnek, az pedig a változás hatásának 
a kollégák közötti elterjesztésével válaszol. 

Egy másik megközelítés lehet, ha a Közvetítő osztályban külön értesítő felületet ha- 
tározunk meg, melynek segítségével a kollégák közvetlenebbül kommunikálhatnak. 
A Smalltalk/V for Windows a képviselet egy formáját alkalmazza: a kollégák a köz- 
vetítővel való társalgás folyamán saját magukat paraméterként adják át, így a közve- 
títő azonosíthatja a küldőt. Példakódunk is erre a megközelítésre épül, a Smalltalk/Vv 
megvalósítást pedig az Ismert felhasználások részben részletesebben is bemutatjuk. 


Példakód 


A Feladat részben bemutatott betűtípus-választó párbeszédablakot egy Párbeszédablak- 
Irányító segítségével valósítjuk meg. A DialogDirector (Párbeszédablaklrányító) elvont 
osztály az irányítók felületét határozza meg. 


class DialogDirector ( 
public: 


virtual "DialogDirector(); 


virtual void ShowDialogt() ; 
virtual void WidgetChanged(WidgetY) - 0; 


protected: 


ha 


DialogDirector ( ) ; 
virtual void CreateWidgets() - 0; 


A Widget (Vezérlő) a grafikus vezérlők elvont alaposztálya, amely ismeri az irányítóját. 


class Widget ( 
public: 


Widget (DialogDirectort) ; 
virtual void Changed( ) ; 
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virtual void HandleMouse(MouseEventg event) ; 
Afs zs 

private: 
DialogDirectortr director; 

1; 


A Changed (Megváltozotb) az irányító WidgetChanged (VezérlőMegváltozot?) műveletét 
hívja meg. A vezérlők e művelet meghívásával tájékoztatják az irányítót, hogy valamilyen 
esemény történt. 


void Widget::Changed () ( 
.director-:WidgetChangedíthis) ; 
) 


A DialogDirector alosztályai a WidgetChanged felülbírálásával irányítják a megfelelő 
vezérlőket, A vezérlő átad egy önmagára mutató hivatkozást argaumentumként a Widget - 
Changed műveletnek, így az irányító azonosíthatja a megváltozott vezérlőt. A Dialog- 
Director alosztályok a CreateWidgets (LétrehozVezérlők) műveletet tisztán virtuális- 
ként felülírják, így hozzák létre a vezérlőket a párbeszédablakban. 


A ListBox, az EntryField és a Button (IistaMező, BeviteliMező, Gomb) a Widget al- 
osztályai a felhasználói felület elemei számára. A ListBox a listában kijelölt elem kiolvasá- 
sához a GetSelection (SzerezKijelölés) műveletet biztosítja, míg az EntryField 
SetText (BeállítSzöveg) művelete új szöveget helyez a mezőbe. 


class ListBox : public Widget ( 
public: 
ListBox(DialogDirector" ) ; 


virtual const chart GetSelection(); 
virtual void SetList(Listcchartot listItems) ; 
virtual void HandleMouse(MouseEventg event); 
ÉR a ie 

1; 


class EntryField: public Widget ( 
püblic: 
EntryField(DialogDirectort ) ; 


virtual void SetText(const chart text); 
virtual const char! GetText () ; 

virtual void HandleMouse(MouseEventő event); 
Bed méssős 
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A Button egy egyszerű vezérlő, amely a gomb megnyomásakor meghívja a Changed 
(Megváltozott) műveletet. Ez a HanáleMouse (KezelEgér) megvalósításában történik: 


class Button: public Widget ( 
public: 
Button(DialogDirector" ) ; 


virtual void SetText(const char! text); 
virtual void HandleMouse(MouseEventg event) ; 


Ke snös 
1; 
void Button: :HandleMouse(MouseEventg event) ( 
Tésss 
Changed ( ) ; 


) 


A párbeszédablak vezérlői között a FontpialogDirector (BetűtípusPárbeszédablak- 
Irányító) közvetít, amely a DialogDirector alosztálya: 


class FontDialogDirector : public DialogDirector ( 
public: 

FontDialogDirectot ( ) ; 

virtual "FontDialogDirectot ( ) ; 

virtual void WidgetChanged(Widget" ) ; 


protected: 
virtual void CreateWidgets-( ) ; 


private: 
Buttont . ok; 
Buttont  cancel; 
ListBoxt  fontList; 
EntryFieldt . fontName; 
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A FontDialogDirector számon tartja az általa megjelenített vezérlőket. A Create- 
Widgets felülírásával létrehozza azokat és előkészíti a rájuk mutató hivatkozásokat: 


void FontDialogDirector: : reateWidgets () ( 
-ok - new Button(this) ; 
.Cancel - new Button(this) ; 
.fontList - new ListBoxíthis) ; 
.-fontName - new EntryFieldí(this); 


// a listamező feltöltése az elérhető betűtípus-nevekkel 


// a párbeszédablak vezérlőinek elkészítése 





Közvetítő 
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A vezérlők helyes együttműködéséről a WidgetChanged (VezérlőMegváltozott) gon- 
doskodik: 


void FontDialogDirector::WidgetChanged ( 
Widget "theChangedWidget 
) € 
if (theChangedWidget --  fontList) ( 
fontName-:sSetText( fontList-sGetSelection( ) ) ; 


) else if (theChangedWidget -- ok) ( 
// a betűtípus megváltoztatása és az ablak bezárása 
NAT evés és 

) else if (theChangedWidget --  cancel) ( 


// a párbeszédablak bezárása 
) 
) 


A WidgetChanged bonyolultsága a párbeszédablak összetettségével egyenesen arányo- 
san nő. A nagy párbeszédablakok természetesen egyéb okokból kifolyólag sem kívánato- 
sak, de a közvetítő bonyolultsága háttérbe szoríthatja a tervezési minta előnyeit. 


Ismert felhasználások 


Vezérlők közötti közvetítőként mind az ET--4 (WGM88], mind a THINK C osztálykönyvtára 
[ISym93bl Irányító-szerű objektumokat használ a párbeszédablakokban. 


A Smalltalk/V for Windows alkalmazások szerkezete is a Közvetítő mintán alapul [LaL94]. 
Ebben a környezetben az alkalmazások egy Window (Ablak) objektumból állnak, amely 
,ablaktáblákat" (Pane) tartalmaz. A könyvtár számos előre elkészített Pane objektumot 
CTextPane, ListBox, Button stb.) bocsát rendelkezésre; ezek alosztályok létrehozása nélkül 
felhasználhatók. A programfejlesztőnek csak a ViewManager (Nézetkezelő) osztályból kell 
alosztályokat származtatnia; ez az osztály felel a táblák összehangolásáért. Tehát a View- 
Manager a közvetítő, a táblák pedig csak saját nézetkezelőjüket ismerik, amely az adott táb- 
la tulajdonosának" számít, A táblák közvetlenül nem hivatkoznak egymásra. Az alábbi ob- 
jektumdiagram egy alkalmazás futásidejű pillanatfelvételét mutatja: 


(7 














aViewManager 


textP: 
aTextPanc Halált 
tulajdonos jjlátásedteánnáetat. Te a... : .] 
aButton 
tulajdonos 9—] 
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A Pane és ViewManager objektumok közötti kapcsolattartáshoz a Smalltalk/V eseményeket 
használ. A táblák eseményt váltanak ki, ha információt akarnak nyerni a közvetítőtől, vagy 
közölni kívánják vele, hogy valami fontos dolog történt. Az események egy szimbólummal 
(pl. tselect) azonosítják az eseményt. Az esemény kezeléséhez a nézetkezelő bejegyez- 
tet egy metódusválasztót a táblával; ez a választó lesz az esemény kezelője, és meghívására 
minden esetben sor kerül, ha valamilyen esemény történik. 


Az alábbi kódrészlet azt mutatja be, hogyan jön létre egy ListPane objektum egy View- 
Manager alosztályon belül, és a nézetkezelő hogyan jegyezteti be a select esemény ese- 
ménykezelőjét: 


self addSubPane: (ListPane new j 
paneName: "myListPane!" ; 
owner: self; 
when: tselect perform: tilistSelect:). 


A Közvetítő minta egy másik alkalmazása az összetett frissítések lebonyolítása. Erre a Meg- 
figyelő mintánál bemutatott VáltozásKezelő (ChangeManager) osztály ad példát. A Válto- 
zásKezelő alanyok és megfigyelők között közvetít, hogy elkerülhessük a felesleges több- 
szöri frissítést. Amikor egy objektum megváltozik, értesíti a VáltozásKezelőt, amely az ob- 
jektumtól függő más objektumok értesítésével összehangolja a frissítést. 


Ehhez hasonló alkalmazást láthatunk a Unidraw grafikai keretrendszerben (VL90], ahol 
a CSolver nevű osztály az úgynevezett ,konnektorok" közötti kapcsolati kötéseket kezeli. 
A grafikus szerkesztők objektumai különböző módokon összekapcsolva jelenhetnek meg. 
A konnektorok (összekötők) azokban a programokban lehetnek hasznosak, amelyekben 
a kapcsolatok fenntartása automatikus (ilyenek például a diagramszerkesztők vagy az 
áramkörtervező rendszerek). A CSolver a konnektorok közötti közvetítő, amelynek felada- 
ta a kapcsolati kötések feloldása és a konnektorok helyének frissítése a kötések változásá- 
nak megfelelően. 


Kapcsolódó minták 


Homlokzat: A Homlokzat tervezési minta annyiban különbözik a Közvetítőtől, hogy objek- 
tumok elvont alrendszere révén kényelmesebb felületet biztosít. Protokollja egyirányú, va- 
gyis a Homlokzat objektumok intézhetnek kérelmeket az alrendszer osztályaihoz, de ez 
visszafelé nem működik. A Közvetítő minta ezzel szemben olyan együttműködési lehetősé- 
geket biztosít, amiket a kolléga objektumok nem képesek biztosítani, a protokoll pedig 
többirányú. 


Megfigyelő: A kollégák a közvetítővel a Megfigyelő minta segítségével tarthatnak fenn 
kapcsolatot. s 
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Emlékeztető 


Viselkedési objektumminta 
Cél 


Az egységbe zárás (betokozás, enkapszuláció) megsértése nélkül rögzíteni és felfedni egy 
objektum belső állapotát, hogy az később ebbe az állapotba visszaállítható legyen. 


Egyéb nevek 


Memento, Pillanatfelvétel, Token 


Feladat 


Időnként szükséges lehet egy objektum belső állapotának rögzítése. Ez különösen akkor 
fontos, amikor ellenőrző pontokat vagy művelet-visszavonási lehetőségeket valósítunk 
meg, melyek segítségével a felhasználó , kihátrálhat" egyes műveletekből, vagy a program 
hiba utáni helyreállítást végezhet. Ahhoz, hogy objektumokat egy korábbi állapotba állít- 
hassunk vissza, valahová állapotinformációkat kell mentenünk. Az objektumok azonban 
általában elrejtik állapotukat; más objektumok nem férhetnek hozzá, tehát a külső mentés 
sem lehetséges. Ezen állapot felfedése az egységbe zárás megsértése lenne, aminek a prog- 
ram megbízhatósága és bővíthetősége látná kárát. 


Vegyünk példaképpen egy grafikus szerkesztőt, amely támogatja az objektumok össze- 
kapcsolását. A felhasználó összeköthet két téglalapot egy vonallal, és a téglalapok össze- 
kötve maradnak akkor is, ha a felhasználó valamelyiküket elmozdítja. A szerkesztő gondos- 
kodik róla, hogy a kapcsolat fenntartásához a vonal megnyúljon. 





Az objektumok közötti kapcsolódások fenntartásának egy jól ismert módja a megszorítás- 
feloldó rendszerek használata. Ezt a szolgáltatást egy MegszorításFeloldó (ConstraintSolver) 
objektumba zárhatjuk, amely rögzíti a létrehozott kapcsolatokat, és azokat leíró matema- 
tikai egyenleteket állít elő. Amikor a felhasználó létrehoz egy kapcsolatot vagy más módon 
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megváltoztatja a diagramot, az objektum ezeket az egyenleteket oldja meg (solve), majd 
számításainak eredményét felhasználva újrarendezi a grafikus elemeket, hogy a kapcsola- 
tok megfelelően megmaradjanak. 


Egy ilyen típusú programban a művelet-visszavonás támogatása egyáltalán nem olyan 
könnyű, mint amilyennek tűnik. Egy mozgató művelet visszavonására kézenfekvőnek 
látszhat a megtett távolság tárolása, és ugyanakkora távolság megtétele visszafelé, ez azon- 
ban nem garantálja, hogy minden objektum ugyanott fog megjelenni, ahol eredetileg volt. 
Ha a kapcsolatról nem gondoskodunk megfelelően, a téglalap egyszerű visszafelé mozga- 
tása az eredeti helyére nem feltétlenül jár a kívánt eredménnyel. 


A MegszorításFeloldó nyilvános felülete általában nem elégséges a pontos visszavonáshoz. 
A visszavonó műveleteknek szorosabban kell együttműködniük a MegszorításFeloldóval 
a korábbi állapot visszaállításához, de az objektum belső szerkezetét nem szabad felfed- 
nünk előttük. 


A problémát az Emlékeztető tervezési mintával oldhatjuk meg. Az emlékeztető olyan objek- 
tum, amely egy másik objektum, a kezdeményező (originator) belső állapotáról készít pilla- 
natfelvételt. A visszavonó művelet a kezdeményezőtől emlékeztetőt kér, amikor ellenőriz- 
nie kell annak állapotát. Az emlékeztető kezdeti értéke az aktuális állapotot jellemző infor- 
máció lesz. Az emlékeztetőben csak a kezdeményező tárolhat, illetve csak ő nyerhet ki on- 
nan információt, más objektumok számára az emlékeztető átlátszatlan", 


A grafikus szerkesztő imént tárgyalt példájában a MegszorításFeloldó a kezdeményező. 
A visszavonás folyamata az események következő láncolatából áll: 


1. A szerkesztő mozgató művelet , mellékhatásaként" emlékeztetőt kér a Megszorítás- 
Feloldótól. 

2. A MegszorításFeloldó létrehozza és átadja az emlékeztetőt, ami ebben az esetben 
a FeloldóÁllapot (SolverState) osztály példánya. A FeloldóÁllapot emlékeztető olyan 
adatszerkezeteket tartalmaz, amelyek leírják a MegszorításFeloldó belső egyenletei- 
nek és változóinak jelenlegi állapotát. 

3. Később, amikor a felhasználó visszavonja a mozgató műveletet, a szerkesztő vissza- 
adja a FeloldóÁllapotot a MegszorításFeloldó objektumnak. 


Emlékeztető 
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4. A Feloldóállapotban tárolt adatok alapján a MegszorításFeloldó megváltoztatja belső 
szerkezeteit, hogy az egyenleteket és változókat pontosan visszaállíthassa korábbi 
állapotukba. 


A fenti lépések lehetővé teszik a MegszorításFeloldó számára, hogy más objektumokra bíz- 
za a korábbi állapot visszaállításához szükséges információkat, anélkül, hogy belső szerke- 
zetét felfedné előttük. 


Alkalmazhatóság 
Az Emlékeztető mintát az alábbi esetekben célszerű alkalmazni: 
s Egy objektum (vagy objektumrész) állapotáról pillanatfelvételt kell készíteni, hogy 
később ebbe az állapotba visszaállítható legyen, és 


e az állapotot közvetlenül lekérdező felület felfedné a megvalósítás részleteit, és meg- 
sértené az objektum egységbe zárását. 


Szerkezet 


Kezdeményező 





MJ tal 
retum new Emlékeztetőlállapot) állapot — m-5 SzerezÁllapot() 


Résztvevők 


s Emlékeztető (FeloldóállapoD 

- A Kezdeményező (Originator) objektum belső állapotát tárolja. Csak annyi infor- 
mációt raktároz el, amennyit szükséges. 

— Megakadályozza, hogy a kezdeményezőn kívül más objektumok is hozzáférhesse- 
nek az adatokhoz. Az emlékeztetőknek két felületük van. Az Intéző (Caretaker) 
csak egy keskeny felületet lát, ezért mást nem tehet, csak továbbadhatja az emlé- 
keztetőt más objektumoknak, a Kezdeményező ezzel szemben széles felületet, így 
minden adathoz hozzáférhet, amire szüksége van korábbi állapotának visszaállítá- 
sához. Ideális esetben csak az emlékeztetőt készítő kezdeményező számára enge- 
délyezett, hogy az emlékeztető belső állapotához hozzáférjen. 
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e  Kezdeményező (MegszorításFeloldó) 
— Emlékeztetőt készít, ami az aktuális belső állapotának pillanatfelvételét tartalmazza. 
-— Az emlékeztető segítségével visszaállítja korábbi belső állapotát. 
e Intéző (visszavonó rendszer) 
— Az emlékeztető biztonságáért felel. 
— Az emlékeztető tartalmát soha nem vizsgálja, azon műveleteket nem végez. 


Együttműködés 
. Az intéző emlékeztetőt kér a kezdeményezőtől, tárolja egy ideig, majd visszaadja an- 
nak, amint azt a következő együttműködési diagram is ábrázolja: 
egyintéző egyKezdeményező egyEmlékeztető 


b LétrehozEmlékeztetőt) 


1 
a 
1 
, 






] 





BeállítEmlékeztetőfegyEmlékeztető) 








Az intéző abban az esetben nem adja vissza az emlékeztetőt a kezdeményezőnek, ha 
annak nincs szüksége rá a korábbi állapot visszaállításához. 

" Az emlékeztetők passzívak, állapotukat csak az őket létrehozó kezdeményező kér- 
dezheti le vagy változtathatja meg. 


Következmények 


Az Emlékeztető minta előnyei és hátrányai a következők: 


1. Megőrzi az egységbe zárás határait. Az Emlékeztető minta segítségével elkerülhet- 
jük azon információk felfedését, amelyeket csak a kezdeményezőnek szabad ismer- 
nie, de a tárolás ettől függetlenül az objektumon kívül történik. A minta elszigeteli 
a kezdeményező esetleg bonyolult belső szerkezetét a többi objektumtól, így meg- 
őrzi az egységbe zárás határait. 
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2. Egyszerűbbé teszi a kezdeményező objektumot. Az egységbe zárást megőrző más 
szerkezetekben a kezdeményező számon tartja az ügyfelek által kért belső állapotok 
változatait, ami a tárolás kezelésének minden terhét a kezdeményező vállára helyezi. 
Az, hogy az ügyfelek maguk kezelik a kért állapotot, egyszerűbbé teszi a kezdemé- 
nyező felépítését, és azt is szükségtelenné teszi, hogy az ügyfeleknek értesíteniük 
kelljen a kezdeményezőt, ha munkájukkal végeztek. 

3. Az emlékeztetők használata költséges lehet. Az emlékeztetők jelentős többletterhet 

róhatnak a programra, ha a kezdeményezőnek nagy mennyiségű adatot kell az em- 

lékeztetőbe másolnia, vagy ha az ügyfelek gyakran kérnek, illetve adnak vissza em- 
lékeztetőket. A tervezési minta alkalmazása csak akkor éri meg, ha a kezdeményező 
egységbe zárása és visszaállítása ,olcsó". (Lásd még a fokozatosságról írottakat 

a Megvalósítás részben.) 

A keskeny és széles felületek meghatározása nem mindig könnyű. Egyes nyelvekben 

nehéz biztosítani, hogy az emlékeztető állapotához csak a kezdeményező férhessen 

1ozzá. 

5. Az emlékeztetők kezelésének rejtett költségei vannak. Az Intéző felel az emlékeztetők 

törléséért, csakhogy arról már nincs fogalma, mennyi adat tárolódik az emlékeztető- 

ben, így az egyébként egyszerű intéző az emlékeztetők tárolásához jelentős tárhe- 
yet emészthet fel. 


Heti 


Megvalósítás 


Az Emlékeztető minta megvalósítása során többek között két dologra kell figyelnünk: 


1. Nyelvi támogatás. Az emlékeztetők két felülettel rendelkeznek: egy szélessel a kez- 
deményező, és egy keskennyel a többi objektum számára. Ideális esetben a megva- 
ósításra használt nyelv a statikus védelem két szintjét támogatja. A C-t például az- 
zal, hogy a kezdeményezőt az emlékeztető barátjává, az emlékeztető széles felületét 
pedig priváttá tehetjük. Csak a keskeny felületet kell nyilvánosként meghatároz- 
nunk. Lássunk egy példát: 

elass State; 





class Originator ( 
public: 
Mementot CreateMemento(( ) ; 
void SetMemento(const Memento? p) ; 
tes a 
private: 
State" , state; // belső adatszerkezetek 
9 ESTE 
); 


class Memento ( 
public: 
// keskeny nyilvános felület 
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virtual "Memento( ) ; 
private: 
// csak a Kezdeményező számára elérhető privát tagok 
friend class Originator; 
Memento ( ) ; 


void SetState(State") ; 
Statet GetState(); 
82 

private: 
Statet state; 
Ze sBs 

); 


2. A változások fokozatos tárolása. Ha az emlékeztetők létrehozása és visszaadása 


a kezdeményezőnek előre látható módon zajlik, megtehetjük, hogy az emlékeztető- 
ben csak az eredeti állapothoz képest beállt változásokat rögzítjük. 

Egy előzménylistában található visszavonható parancsok például emlékeztetők se- 
gítségével biztosíthatják, hogy visszavonáskor pontosan helyreálljon a korábbi álla- 
pot (ásd a Parancs tervezési mintáj. Az előzménylista meghatározza, milyen sor- 
rendben lehet a parancsokat visszavonni és újból végrehajtani, így az emlékeztetők- 
nek elég csak a parancsok által előidézett változásokat tárolni, az érintett objektu- 
mok teljes állapotát nem szükséges. A Feladat részben feljebb bemutatott példában 
a MegszorításFeloldó csak azokat a belső szerkezeteket tárolja, amelyek megváltoz- 
nak, hogy a téglalapokat összekötő vonalakat megtartsák, nem pedig az objektumok 
abszolút helyzetét. 


Példakód 


Az itt szereplő Ct-- kód a korábban tárgyalt MegszorításFeloldó (ConstraintSolver) példá- 
hoz tartozik. A grafikus objektumok egyik helyről a másikra mozgatására, illetve ezen mű- 
velet visszavonására MoveCommand (MozgatParancs) objektumokat használunk (lásd a Pa- 
rancs tervezési mintát). A grafikus elemek mozgatásához a szerkesztő a parancs Execute 
(VégrehajO műveletét hívja meg, a visszavonáshoz pedig az Unexecute-ot (Visszavon). 
A parancs tárolja a célobjektumot, a megtett távolságot, ésa ConstraintSolverMemento 
(MegszorításFeloldóEmlékeztető) nevű emlékeztető egy példányát, amely a megszorítás- 
feloldó állapotát rögzíti. 


class Graphic; 


7// a szerkesztő grafikus objektumainak alaposztálya 


class MoveCommand ( 
public: 


MoveCommand (Graphict target, const Point6 delta) 
void Execute(); 
void Unexecute ( ) ; 


private: 
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ConstraintSolverMementot . state; 

Point ,. delta; 

Graphict target; 

); 

A kapcsolatokat a ConstraintSolver osztály hozza létre. Kulcsfüggvénye a Solve (Fel- 
old), amely az Adáconstraint (HozzáadKötés) művelettel bejegyzett kapcsolatokat oldja 
fel. A visszavonás támogatásához a ConstraintSolver állapota a CreateMemento 
(LétrehozEmlékeztető) művelettel tehető , külsővé", amely az állapotot egy Constraint- 
SolverMemento példányba helyezi. A megszorításfeloldó a SetMemento (BeállítEmlé- 
keztető) hívásával állítható vissza korábbi állapotába. A ConstraintSolver Egyke. 


class ConstraintSolver ( 
public: 
static ConstraintSolver!t Instance(); 


void Solve(); 
void AddConstraint( 
Graphict startConnection, Graphict endConnection 
); 
void RemoveConstraint( 
Graphict startConnection, Graphict endConnection 
); 
ConstraintSolverMementot CreateMemento( ) ; 
void SetMemento(ConstraintSolverMementos ) ; 
private: 
// nem triviális állapot és műveletek 
// a kapcsolat létrehozásához 
1 


class ConstraintSolverMemento ( 
public: 

virtual "ConstraintSolverMemento( ) ; 
private: 

friend class ConstraintSolver; 

ConstraintSolverMemento ( ) ; 


// privát megszorításfeloldó-állapot 
Hi 


A fenti felületekkel a következő módon valósíthatjuk meg a MoveCommand Execute és 
Unexecute tagjait 


void MoveCommand: : Execute () ( 
ConstraintSolvert solver - ConstraintSolver : : Instance ( ) ; 
.state - solver-—sCreateMemento(); // emlékeztető létrehozása 


.target-sMove( delta); 
solver-5Solve() ; 
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void MoveCommand: :Unexecute () ( 
ConstraintSolvery solver - ConstraintSolver: : Instance( ) 
.-target-sMove(- delta); 
solver-5SetMemento(. state) ; // az állapot visszaállítása 
solver-sSolve() ; 


1 


Az Execute a grafika mozgatása előtt kér egy ConstraintSolverMemento emlékezte- 
tőt; az Unexecute visszahelyezi a grafikát, visszaállítja a megszorításfeloldó korábbi álla- 
potát, végül pedig arra utasítja azt, hogy számítsa ki a kapcsolatot. 


Ismert felhasználások 


Az előző példakód a Unidraw kapcsolatokat támogató CSolver osztályán IVL90] alapult. 


A Dylan lApp92] gyűjteményei egy olyan bejáró felületet biztosítanak, ami szintén az Emlé- 
keztető mintára épül. E gyűjtemények ismerik az vállapotobjektum" fogalmát, ami egy 
olyan emlékeztető, amely a bejárás állapotát jelöli. A gyűjtemények a bejárás állapotának 
ábrázolására bármilyen módszert választhatnak, az ügyfelek elől az tökéletesen rejtve ma- 
rad. A Dylan bejárási megközelítése Cs nyelven valahogy így festene: 


templatexclass Items 

class Collection ( 

public: 
Collection() ; 


IterationStatet CreatelnitialState(); 

void Next (IterationStater") ; 

bool IsDone(const IterationStater) const; 

Item CurrentItem(const IterationStater) const; 
IterationStatet Copy(const IterationState") const; 


void Append(const Itemg); 

void Remove(const Itemr6); 

ET s ús 

); 

A CreatelnitialState (LétrehozkKezdetiÁllapo)) egy kezdőértékkel ellátott Itera- 
tionsState (BejárásállapoD objektumot ad vissza a gyűjteménynek. A Next (Következő) 
az állapotobjektumot a bejárás következő pozíciójára állítja, ezzel növelve a bejárási inde- 
xet. Az IsDone (Kész) értéke true lesz, ha a Next túllépett a gyűjtemény utolsó elemén. 
A CurrentItem (Aktuális elem) követi az állapotobjektum hivatkozását, és a gyűjtemény 
hivatkozott elemét adja vissza, a Copy (Másol) pedig az adott állapotobjektum másolatát. 
Ezzel a bejárás egy adott pontját jelölhetjük meg. 


Ha adott egy ItemType (ElemTípus) nevű osztály, példányainak gyűjteményét a követ- 
kező módon járhatjuk be: 
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class ItemType ( 


públic: 
void ProcessS(); 
TT gs 

hó 


CollectioncItemTypeyr: aCollection; 
IterationStatet state; 


state - aCollection.CreatelnitialState() ; 


while (!aCollection.IsDone(state)) ( 
acCollection. CurrentItem(state) -—s5Process() ; 
aCollection.Next (state) ; 

) 


delete state;7 
Az emlékeztető alapú bejárási felületnek két érdekes előnye van: 


1. Egy gyűjteményhez egynél több állapot is tartozhat. (Ugyanez igaz a Bejáró mintára is.) 

2. A bejárás támogatásához nincs szükség a gyűjtemény egységbe zárásának megsérté- 
sére. Az emlékeztetőt csak maga a gyűjtemény értelmezi, más nem férhet hozzá. 
A bejárás más megközelítéseinél előfordulhat, hogy az egységbe zárást fel kell tör- 
nünk, például ha a bejáró osztályokat gyűjteményosztályaik barátjává kell tennünk 
ásd a Bejáró mintán. Az emlékeztető alapú megvalósításban ennek éppen a fordí- 
tottja a helyzet: a Collection (Gyűjtemény) az IteratorState barátja. 


A OOCA megszorításfeloldó elemkészlet az emlékeztetőkben csak a külöbségeket tárolja 
IHHMV921]. Itt az ügyfelek egy emlékeztetőt kapnak, amely a kötések egy bizonyos rend- 
szerére adott aktuális megoldás jellemzőit tartalmazza. Az emlékeztető csak azokat a válto- 
zókat tárolja, amelyek az utolsó megoldás óta megváltoztak, ami általában csak a változók 
egy kis részhalmaza. E részhalmaz elegendő ahhoz, hogy a feloldó visszatérhessen a meg- 
előző megoldáshoz. A COCA az előzményekre támaszkodik; a korábbi megoldások a köz- 
benső megoldások helyreállított emlékeztetőiből állíthatók vissza, így az emlékeztetők sor- 
rendje nem módosítható. 


Kapcsolódó minták 


Parancs: A parancsok emlékeztetőket alkalmazhatnak a visszavonható műveletek állapotá- 
nak rögzítésére. 


Bejáró: Az emlékeztetők a korábban leírt módon bejárás támogatására is használhatók. 





" Megfigyelhetjük, hogy a példában az állapotobjektumot a bejárás végén töröljük. A delete (töröl) azonban 
nem hívódik meg, ha a ProcessItem (FeldolgozElem) kivételt vált ki, így szemét keletkezik. Ez a C$--szal 
szemben a szemétgyűjtéssel rendelkező Dylan-ben nem okoz gondot. A problémára a Bejáró mintánál láthat- 
tunk egy megoldást. 
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Megfigyelő 
Viselkedési objektumminta 
Cél 


Objektumok között egy-sok függőségi kapcsolatot létrehozni, így amikor az egyik objektum 
állapota megváltozik, minden tőle függő objektum értesül erről és automatikusan frissül. 


Egyéb nevek 


Observer, Figyelő, Dependents (Függőségek), Publish-Subscribe (Közzététel-Előfizetés) 


Feladat 


Gyakori probléma, hogy amikor egy rendszert együttműködő osztályokra bontunk, gon- 
doskodnunk kell a kapcsolatban álló objektumok következetességének fenntartásáról is. 
Ezt többnyire nem szoros csatolással szeretnénk elérni, hiszen ez csökkentené az osztályok 
újrahasznosíthatóságát. 


Számos, grafikus felhasználói felületekhez készített elemkészlet például különválasztja 
a megjelenítést a mögötte megbúvó alkalmazásadatoktól IKP88, LVC89, P--88, WGM88], így 
az e kettőt meghatározó osztályok egymástól függetlenül újrahasznosíthatók, bár természe- 
tesen együtt is működhetnek. Különböző megjelenítési módszereket használva ugyanab- 
ban az alkalmazási adatobjektumban egy táblázat objektum és egy oszlopdiagram objek- 
tum is megjeleníthet információt. A táblázat és az oszlopdiagram nem tudnak egymásról 
(bár úgy viselkednek, mintha tudnának), így elég csak a számunkra szükséges objektum új- 
rahasznosítása. Amikor a felhasználó módosít egy adatot a táblázatban, az oszlopdiagram 
azonnal tükrözi a változtatásokat, és ugyanez igaz megfordítva is. 


megfigyelők 


TS 












































a. 
a- 509 E változási értesítés 
b - 3096 
c - 209 —-——-s kérelmek, módosítások 
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Ez a viselkedés maga után vonja, hogy a táblázat és az oszlopdiagram az adatobjektumtól 
függ, így az annak állapotában bekövetkező bármilyen változás ezek értesítését igényli. 
A függő objektumok számát persze nem szükséges kettőre korlátozni; ugyanazt az adatot 
korlátlan számú felhasználói felületi elemmel megjeleníthetjük. 


A Megfigyelő minta azt írja le, hogyan alakíthatjuk ki ezeket a kapcsolatokat. A minta kulcs- 
objektumai az alany (subject) és a megfigyelő (observer). Az alanynak bármennyi, tőle függő 
megfigyelője lehet, amelyek az alany állapotában beálló minden változásról értesülnek, Ez- 
után a megfigyelők kérelmet intéznek az alanyhoz, hogy összehangolhassák állapotukat az 
alanyéval. 


Ezt a fajta együttműködést közzététel-előfizetés néven is ismerik. Az alany az értesítések 
,közzétevője", amely az értesítéseket anélkül küldheti el, hogy tudná, kik a megfigyelői, 
a megfigyelők — amelyekből bármennyi lehet — pedig , előfizethetnek" ezen értesítésekre. 


Alkalmazhatóság 


A Megfigyelő tervezési mintát a következő helyzetekben célszerű alkalmazni: 


s Egy fogalomhoz két ábrázolás kapcsolódik, és egyik a másiktól függ. Ezen ábrázolá- 
sok külön objektumba zárása lehetővé teszi, hogy egymástól függetlenül módosít- 
hassuk vagy újrahasznosíthassuk őket. 

e Egy adott objektum módosítása más objektumok módosítását igényli, és nem tudjuk, 
hány objektumot kell megváltoztatnunk. 

e Egy adott objektumnak képesnek kell lennie arra, hogy anélkül értesítsen más ob- 
jektumokat, hogy feltételezésekkel élne azok kilétéről. Más szavakkal, az említett 
objektumok között nem szeretnénk szoros csatolást létrehozni. 























Szerkezet 

I Alany] revferetők 

Csatol(Megfigyelő) 

LeválasztíMegfigyelő) 

for all o in megfigyelők ( 
ds] jánztkeztlelszt 7-7[  0—riissítő) 
ÉN ; 
NI] 
et) .. ) megfigyelőÁllapot — 

zárás esze 

SzerezÁllapot() O - - - f. - 

dlanyállpot 7) 
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Résztvevők 


e Alany 
— Ismeri a megfigyelőit. Az Alanyt (Subjec0) korlátlan számú Megfigyelő (Observer) 
objektum figyelheti meg. 
— Felületet biztosít a Megfigyelő objektumok csatolására és leválasztására. 
e Megfigyelő 
— Frissítő felületet határoz meg az alanyban bekövetkező változásokról értesítendő 
objektumok számára. 
e  KonkrétAlany 
- A KonkrétMegfigyelő (ConcreteObserver) objektumok számára érdekes állapotot 
tárolja. 
— Értesítést küld megfigyelőinek, ha állapota megváltozik. 
e  KonkrétMegfigyelő 
— Hivatkozást tart fenn egy KonkrétAlany (ConcreteSubject) objektumra. 
— Tárolja azt az állapotot, amelynek összhangban kell maradnia az alany állapotával. 
— Megvalósítja a megfigyelőt frissítő felületet, így állapotát összehangolhatja az 





alanyéval. 
Együttműködés 


" A KonkrétAlany értesíti megfigyelőit, ha olyan változás történik, amelynek eredmé- 
nyeképpen azok állapota eltérne a sajátjától., 

s Miután értesült a konkrét alanyban bekövetkezett változásról, a KonkrétMegfigyelő 
információt kérhet az alanytól, majd ezen információ segítségével összehangolhatja 
állapotát az alanyéval. 

Az alábbi együttműködési diagram egy alany és két megfigyelő együttműködését il- 
lusztrálja: 


egyKonkrétAlany egyKonkrétMegfigyelő másikKonkrétMegfigyelő 


h. BeállítÁllapot() 


Értesítt) 











Frissít() 





SzerezÁllapot() 





Frissít() 


SzerezÁllapot() 
ha 
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Megfigyelhetjük, hogyan halasztja el a módosítást kezdeményező Megfigyelő objektum sa- 
ját frissítését, amíg értesítést nem kap az alanytól. Az Értesít (Notify) műveletet nem mindig 
az alany hívja meg; meghívhatja egy megfigyelő vagy egy teljesen más típusú objektum is. 
A Megvalósítás részben erre is megnézünk néhány lehetőséget. 


Következmények 


A Megfigyelő minta lehetővé teszi, hogy az alanyokat és megfigyelőket egymástól függetlenül 
módosítsuk. Az alanyok megfigyelőik felhasználása nélkül is újrahasznosíthatók, és viszont. 
Így az alany vagy más megfigyelők megváltoztatása nélkül hozhatunk létre új megfigyelőket. 


A Megfigyelő minta előnyei és hátrányai többek között a következők: 


1. Elvont csatolás az alany és a megfigyelő között. Az alany csupán annyit tud, hogy 

megfigyelői vannak, amelyek mindegyike megfelel az elvont Megfigyelő osztály 
egyszerű felületének, konkrét osztályukat egyáltalán nem ismeri. Így az alanyok és 
megfigyelők csatolása laza és elvont. 
Miután az Alany és a Megfigyelő nem szoros csatolással rendelkezik, a rendszer más- 
más elvont fogalmi szintjéhez tartozhatnak. Az alsóbb szintű alany társaloghat a ma- 
gasabb szintű megfigyelővel, így a rendszer rétegezettsége érintetlen marad. Ha az 
alany és a megfigyelő összekapcsolódna, az előálló objektumnak vagy két réteget 
kellene átfognia (amivel megsértené a rétegezettsége?), vagy választania kellene, 
melyik rétegben kíván , élni" (ami a fogalmi rétegeket tenné tönkre). 

2. Az üzenetszórás támogatása. A szokványos kérelmektől eltérően az alany által kikül- 
dött értesítésnek nem kell meghatároznia fogadóját. Az értesítés automatikusan, üze- 
netszórással (broadcas1) jut el minden érdekelt előfizető objektumhoz. Ezek száma az 
alany számára érdektelen; az ő feladata csupán annyi, hogy értesítse megfigyelőit. Így 
bármikor új megfigyelőket adhatunk a rendszerhez, vagy vehetünk el onnan; az érte- 
sítések kezelése vagy figyelmen kívül hagyása a megfigyelők felelőssége. 

3. Váratlan frissítések. Miután a megfigyelők nem tudnak egymás jelenlétéről, az alany 
módosításának végső költségéről sincs fogalmuk. Egy látszólag jelentéktelen művelet 
az alanyon frissítések láncolatát indíthatja el a megfigyelők és az azoktól függő objek- 
tumok között. Emellett a nem pontosan meghatározott vagy fenntartott függőségi fel- 
tételek zavaros frissítésekhez vezethetnek, amelyek oka nehezen felderíthető. 

A gondot súlyosbítja az a tény, hogy egy egyszerű frissítési protokoll nem árul el 
részleteket arról, mi változott meg az alanyban, így ha más protokollok nem segítik 
a megfigyelőket, a változások okának felderítése kemény dió lehet számukra. 
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Megvalósítás 


Ebben a részben számos, a függőségi rendszer megvalósításával kapcsolatos kérdéssel fog- 
lalkozunk: 


1. Az alanyok hozzárendelése a megfigyelőkhöz. Az alanyok legegyszerűbben úgy kö- 
vethetik nyomon az értesítendő megfigyelőket, ha kifejezett hivatkozásokat tárolnak 
rájuk. Ez azonban túl költséges lehet, ha sok alanyunk de kevés megfigyelőnk van. 
Megoldást jelenthet, ha a kisebb tárhelyért idővel fizetünk, és valamilyen társításos 
(asszociatív) keresést, például egy hasító- vagy kivonattáblát (hash) alkalmazunk az 
alanyok és megfigyelők egymáshoz rendelésére, így a megfigyelővel nem rendelke- 
ző alanyok nem jelentenek társzükséglet-többletet. Másfelől azonban ez a megköze- 
lítés növeli a megfigyelők elérésének költségét. 

2. Egynél több alany megfigyelése. Egyes helyzetekben célszerű lehet, ha a megfigyelő 
egynél több alanytól függ, például ha egy táblázat több adatforráshoz kapcsolódik. 
Ilyen esetekben a Frissít (Update) felületet ki kell bővítenünk, hogy a megfigyelő tud- 
ja, melyik alanytól kapta az értesítést. Az alany egyszerűen átadja magát a Frissít mű- 
velet paramétereként, így a megfigyelő tudni fogja, melyik alanyt kell megvizsgálnia. 

3. Ki indítja el a frissítést? Az alany és megfigyelői az értesítések segítségével maradnak 
összhangban. De vajon melyik objektum hívja meg az Értesít műveletet a frissítés- 
hez? Két lehetőség áll rendelkezésre: 

(a) Az alany állapot-beállító műveleteivel hívatjuk meg az Értesít műveletet, miután 
megváltoztatták az alany állapotát. E megközelítés előnye, hogy nem az ügyfe- 
leknek kell emlékezniük az Értesít meghívására, hátránya pedig, hogy több egy- 
mást követő művelet több egymást követő frissítést von maga után, ami esetleg 
nem túl hatékony. 

(b) Az ügyfelek felelősségévé tesszük, hogy a megfelelő időben meghívják az Értesít 
műveletet. Ennek előnye, hogy az ügyfél több állapotváltozást is megvárhat, mi- 
re elindítja a frissítést, így elkerülhetők a felesleges köztes frissítések. A megkö- 
zelítés hátulütője, hogy az ügyfelek felelőssége a frissítés elindítása, ami azok 
, feledékenysége" miatt valószínűbbé teszi a hibák bekövetkeztét. 

4. Törölt alanyokra mutató árva hivatkozások. Az alanyok törlése nem szabad, hogy 
elárvult hivatkozásokat eredményezzen megfigyelőikben. Az árva hivatkozások el- 
kerülésének egyik módja, ha az alany értesíti a megfigyelőket törléséről, így azok 
megszüntethetik a rá mutató hivatkozást. Pusztán a megfigyelők törlése általában 
nem lehetséges, mert más objektumok hivatkozhatnak rájuk, illetve ők maguk több 
alanyt is megfigyelhetnek. 

5. Az állapot következetességének biztosítása az alanyban az értesítés előtt. Fontos, 
hogy az Értesít meghívása előtt ellenőrizzük, hogy az Alany állapota következetes-e, 
mert a megfigyelők saját frissítésükhöz lekérdezik az alany aktuális állapotát. 

E szabályt akaratlanul is könnyen áthághatjuk, ha az Alany alosztályainak műveletei 

örökölt műveleteket hívnak meg. Az alábbi kódban szereplő értesítés útnak indításá- 

ra például akkor kerül sor, amikor az alany állapota nem megfelelő: 
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void MySubject::Operation (int newValue) (í 
BaseClassSubject : : Operation (newValue) ; 
//értesítés elindítása 


.myInstVar 4- newValue; 
//az alosztály állapotának frissítése (túl késő!) 
) 
Ezt a buktatót úgy kerülhetjük el, ha sablonfüggvényekből küldünk értesítést az elvont 
Alany osztályokban. (A Sablonfüggvény mintát a fejezetben később tárgyaljuk.) Hatá- 
rozzunk meg egy egyszerű műveletet, amelyet az alosztályok majd felülírnak, az Értesít- 
et pedig tegyük a sablonfüggvény utolsó műveletévé; ezzel biztosítjuk, hogy az objek- 
tum állapota megfelelő lesz, amikor az alosztályok felülbírálják az Alany műveleteit. 
void Text::Cut (TextRange r) ( 
ReplaceChange(r) ; // az alosztályok felülírják 
Notify(); 
) 


Mindig jó ötlet rögzíteni, hogy az Alany mely műveletei indítják el az értesítéseket. 
. A megfigyelőfüggő frissítési protokollok elkerülése: a hűző és toló modell. A Megfi- 
gyelő minta különböző megvalósításaiban az alany gyakran kiegészítő információ- 
kat is mellékel a változást jelző értesítéshez, amelyeket a Frissít művelet argumentu- 
maként ad át. Az információ mennyisége megvalósításonként jelentősen eltérhet. 
Az egyik véglet, ha az alany részletes információkkal látja el a megfigyelőket, akár 
kérik azok, akár nem. Ezt hívjuk toló modellnek (push model). A másik véglet a húzó 
modell (pull mode]; ekkor az alany semmit nem küld az értesítésen kívül, és a megfi- 
gyelőknek kell kifejezetten érdeklődniük a részletek felől. 
A húzó modellben az alany nem törődik a megfigyelőkkel, míg a toló modell feltéte- 
lezi, hogy az alanyok legalább részben ismerik megfigyelőik igényeit. Az utóbbiban 
a megfigyelők újrahasznosítása nehezebb, mert az Alany osztályok olyan feltételezé- 
sekkel élnek a Megfigyelő osztályokról, amelyek nem minden esetben bizonyulnak 
igaznak. Más részről viszont a húzó modell kevésbé hatékony, hiszen a megfigye- 
lőknek az alany segítsége nélkül kell megállapítaniuk, mi változott meg. 
. Az ,érdekes" módosítások kifejezett meghatározása. Növelhetjük a frissítés haté- 
konyságát, ha az alany bejegyző felületét úgy bővítjük ki, hogy megengedje olyan 
megfigyelők bejegyzését is, amelyek csak bizonyos eseményeket figyelnek. Amikor 
egy esemény bekövetkezik, az alany csak azokat a megfigyelőket értesíti, amelyek 
bejegyzés szerint az adott esemény iránt , érdeklődnek". E megoldás támogatásának 
egyik módja az aspektusok (szempont, tulajdonság) használata a Subject objektumok- 
ban. A megfigyelők ekkor a következő módon kapcsolódnak az alanyhoz és jelentik 
be, hogy egy bizonyos esemény érdekli őket: 

void Subject::Attach(Observert, Aspectg interest); 
A fenti kódban az interest határozza meg az , érdekes" eseményt. Értesítéskor az 
alany a Frissít (Update) művelet paramétereként adja meg a megfigyelőknek, mely 
aspektusa változott meg: 

void Observer: :Update(Subjectt, Aspectg interest); 
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8. Az összetett frissítések egységbe zárása. Ha az alanyok és megfigyelők közötti függő- 


ségi kapcsolat különösen összetett, külön objektumra lehet szükség, amely gondos- 
kodik e kapcsolatról. Az ilyen objektumokat nevezzük VáltozásKezelőnek (Change- 
Manager). A Változáskezelő célja, hogy minimálisra csökkenthessük azt a munkát, 
ami ahhoz szükséges, hogy az alanyban beállt változást tükrözhessük a megfigye- 
lőkben. Ha egy művelet például számos, egymástól függő alany megváltozását vonja 
maga után, szükség lehet arra, hogy biztosítsuk, a megfigyelők értesítésére csak azu- 
tán kerül sor, hogy minden alany módosítása megtörtént, így elkerülhetjük a megfi- 
gyelők többszöri értesítését. 

A változáskezelőnek három feladata van: 

(a) Az alany összekapcsolása a megfigyelőkkel, és felület biztosítása e kapcsolat 
fenntartásához. Ez megszünteti annak szükségességét, hogy az alanyoknak hi- 
vatkozásokat kelljen fenntartaniuk a megfigyelőkre, és viszont. 

(b) Egy adott frissítési stratégia meghatározása. 

(c) Az alany kérésére az összes függő megfigyelő frissítése. 

A következő diagram a Megfigyelő minta egy egyszerű, változáskezelő alapú megva- 

lósítását mutatja. Itt két egyedi célú változáskezelőt találunk. Az Egyszerűvál- 

tozásKezelő (SimpleChangeManager) , naiv", mindig frissíti az alanyhoz tartozó vala- 
mennyi megfigyelőt. Ezzel szemben a DAGVáltozásKezelő (DAGChangeManager) 
az alanyok és megfigyelőik függőségeinek irányított körmentes gráfjait kezeli. 

Ha egy megfigyelő több alanyt is megfigyel, a DAGVáltozásKezelő a jobb választás. 

Ekkor a kettő vagy több alanyban bekövetkező változások felesleges frissítéseket 

okozhatnak, a DAGVáltozáskKezelő viszont gondoskodik róla, hogy a megfigyelő 

frissítése csak egyszer történjen meg. Ha a többszöri frissítés veszélye nem merül fel, 
az EgyszerűváltozáskKezelő is megfelel. 
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A VáltozáskKezelő a Közvetítő mintára mutat példát. Általában csak egy van belőle, és 
a programban globálisan , ismert". Ehhez az Egyke minta nyújthat segítséget. 

9. Az Alany és Megfigyelő osztályok egyesítése. A többszörös öröklést nem tartalmazó 
programnyelveken (ilyen például a Smalltalk) írt osztálykönyvtárak általában nem ha- 
tároznak meg külön Alany és Megfigyelő osztályokat, hanem azok felületét egyetlen 
osztályban egyesítik. Így olyan objektumokat hozhatunk létre, amelyek egyszerre 
alanyként és megfigyelőként is viselkedhetnek, többszörös öröklés nélkül. 
A Smalltalk nyelvben például az Alany (SubjecD és Megfigyelő (Observer) felületeket 
az Object gyökérosztály határozza meg, így valamennyi osztály számára elérhetők. 


Példakód 
A Megfigyelő (Observer) felületet egy elvont osztály határozza meg: 


cláss Subject; 


class Observer ( 


public: 

virtual "Observer ( ); 

virtual void Update(Subject§ theChangedSubject) - 0; 
protected: 

Observer ( ) ; 


1; 


Ez a megvalósítás minden megfigyelő esetében több alanyt (Subject) támogat. Az Update 
(Frissít) műveletnek átadott alany lehetővé teszi a megfigyelő számára, hogy amennyiben 
több alanyt is megfigyel, megállapíthassa, melyik változott meg. 


Ehhez hasonlóan az Alany (Subject) felületét is egy elvont osztály határozza meg: 


class Subject ( 
public: 


virtual "Subject(); 


virtual void Attach(Observer?) ; 
virtual void Detach(Observert) ; 
virtual void Notify(); 
protected: 
Subject () ; 
private: 
List-Observerts t öbservers; 
hi 


void Subject::Attach (Observer? o) ( 
.-observers-sAppend(0o) ; 


3 
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void Subject::Detach (Observerr o) ( 
.-observers-5Remove (0) ; 


J 


void Subject::Notify () ( 
ListIlteratorcObservert5 i( observers) ; 


for (i.First(); !i.IsDone(); i.Next()) ( 
i.CurrentItem( ) -sUpdate(this) ; 
3 


A ClockTimer (Óraldőzítő) egy konkrét alany, amely az aktuális időt tárolja, és a megfi- 
gyelőket másodpercenként értesíti az idő változásáról. Az egyes időegységek — óra, perc, 
másodperc - lekérdezésére a ClockTimer felület szolgál. 


class ClockTimer : public Subject ( 
public: 
ClockTimetr ( ) ; 


virtual int GetHour(); 
virtual int GetMinute(); 
virtual int GetSecond(); 


void Tick(); 
1; 


A Tick (Ketyeg) műveletet egy belső időzítő hívja meg szabályos időközönként. A Tick 
frissíti a ClockTimer belső állapotát, és meghívja a Not i fy (Értesít) műveletet, hogy érte- 
sítse a megfigyelőket a változásról: 


void ClockTimer::Tick () ( 
// a belső idő frissítése 
PVaza 
Notify(); 


3 


Most meghatározhatunk egy Digitalclock (DigitálisÓra) nevű osztályt, amely megjele- 
níti az időt. Az osztály a grafikus megjelenítéshez a Widget (Vezérlő) osztálytól örököl, 
amelyet a felhasználói felület elemkészlete biztosít. A megfigyelő felületet az Observer 
osztálytól való örökléssel a Digitalclock felületbe skeverjük". 


class DigitalClock: public Widget, public Observer f, 
public: 
DigitalClock(ClockTimer" ) ; 


virtual "DigitalClock(); 
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virtual void Update(Subject") ; 
// az Observer műveletének felülírása 


virtual void Draw(); 
// a Widget műveletének felülírása; 
// a digitális óra kirajzolását határozza meg 
private: 
ClockTimert subject 
1; 


DigitalClock::DigitalClock (ClockTimer?" s) ( 
.subject - s; 
.subject-sAttach(this) ; 


DigitalClock: :"DigitalClock () ( 
.Ssubject-sDetachí(this) ; 
) 


Mielőtt az Update művelet megrajzolja az óra számlapját, ellenőrzi, hogy az értesítő alany 
az óra alanya-e: 


void DigitalClock: :Update (Subject theChangedSubject) ( 


if (theChangedSubject -- subject) ( 
Draw() ; 
) 
) 
void DigitalClock: :Draw () ( 


// az új értékek lekérése az alanytól 


int hour - . subject-—sGetHout ( ) ; 
int minute - . subject-sGetMinute ( ) ; 
77 stb. 


// a digitális óra megrajzolása 


Egy analóg óra (AnalogClock osztály) ehhez hasonlóan határozható meg: 


class AnalogClock : public Widget, public Observer ( 
public: 

AnalogClock(ClockTimer"? ) ; 

virtual void Update (Subject?) ; 

virtual void Draw(); 

VZsas 
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Az alábbi kód egy analóg és egy digitális órát hoz létre, amelyek mindig ugyanazt az időt 
mutatják: 


ClockTimerr timer - new ClockTimer; 
AnalogClockt analogClock - new AnalogClockí(timer) ; 
DigitalClockr digitalClock - new DigitalClock(timer) ; 


A két óra a timer minden , ütésénél" frissül, és újra kirajzolja magát. 


Ismert felhasználások 


A Megfigyelő minta első és talán legismertebb alkalmazása a Smalltalk felhasználói felületi 
keretrendszere, a modell-nézet-vezérlő (Model/View/Controller, MVC) megoldás [KP88a]., 
Itt az MVC Model osztálya az alany, míg a View a megfigyelők alaposztálya. A Smalltalk, az 
ET IWGM88] és a THINK osztálykönyvtár [Sym93bl egy általános függőségkezelő megol- 
dást tartalmaznak: az Alany és Megfigyelő felületeket a rendszer valamennyi osztályának 
szülőosztályába helyezték. 


Ugyanezt a mintát alkalmazza az InterViews [LVC89], az Andrew Toolkit [P--88], és 
a Unidraw [(VL90] felhasználói felületi elemkészlet is. Az InterViews kifejezett Observer 
(megfigyelő) és Observable (megfigyelhető, vagyis alany) osztályokat határoz meg, az 


Andrew nézeteket" és ,adatobjektumokav"; a Unidraw a grafikus szerkesztői objektumokat 
View (megfigyelői) és Subject (alany) részekre bontja. 


Kapcsolódó minták 


Közvetítő: Az összetett frissítések egységbe zárásával a VáltozásKezelő közvetítőként mű- 
ködik az alanyok és megfigyelők között. 


Egyke: A VáltozásKezelő az Egyke minta segítségével egyedivé és globálisan elérhetővé 
tehető. 





Állapot 





g 
Állapot 
Viselkedési objektumminta 
Cél 


Egy adott objektum számára engedélyezni, hogy belső állapotának megváltozásával meg- 
változtathassa viselkedését is. Az objektum ekkor látszólag módosítja az osztályát. 


Egyéb nevek 


State, Objects for States (Állapotobjektumok) 


Feladat 


Vegyünk egy TCPKapcsolat (TCPConnection) nevű osztályt, amely egy hálózati kapcsolatot 
ábrázol. A TCPKapcsolat objektum a következő állapotok valamelyikében lehet: Kapcsolód- 
va (Established), Figyelő (listening), Lezárva (Closed). Amikor az objektum kérelmeket fo- 
gad más objektumoktól, aktuális állapotától függően más-más válaszokat adhat. Egy Meg- 
nyit (Open) kérelem hatása például attól függhet, hogy a kapcsolat éppen Lezárva vagy 
Kapcsolódva állapotban van-e. Az Állapot tervezési minta leírja, hogyan mutathat a TCP- 
Kapcsolat az egyes állapotokban különböző viselkedéseket. 


A minta kulcsa egy TCPÁllapot (TCPState) nevű elvont osztály bevezetése, ami a hálózati 
kapcsolat állapotait ábrázolja. A TCPÁllapot a különböző működési állapotokhoz tartozó 
osztályok közös felületét írja le, alosztályai pedig az állapottól függő viselkedést. A TCP- 
Kapcsolódva (TCPEstablished) és a TCPLezárva (TCPClosed) például a TCPkapcsolat Kap- 
csolódva és Lezárva állapotaira jellemző működést valósítják meg. 


TCPKapcsolat 


TCPÁLlapot 
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A TCPKapcsolat osztály egy állapotobjektumot tart fenn (a TCPÁllapot valamelyik alosztá- 
lyának egy példányát), ami a TCP kapcsolat aktuális állapotát jelöli. Az osztály minden álla- 
potfüggő kérelmet ehhez az objektumhoz továbbít, az pedig végrehajtja a kapcsolat állapo- 
tának megfelelő műveleteket. 


Amikor a kapcsolat állapota megváltozik, a TCPKapcsolat a megfelelő állapotobjektumra 
cseréli az éppen használtat; ha a kapcsolatot például lezárjuk, a TCPKapcsolódva példányt 
egy TCPLezárva példánnyal helyettesíti. 


Alkalmazhatóság 


Az Állapot minta a következő esetekben alkalmazható: 


. Egy objektum viselkedése az állapotától függ, és ezen viselkedést futásidőben az ál- 
lapotnak megfelelően kell változtatnia. 

s A műveletekben hosszú, több részből álló feltételes utasítások találhatók, amelyek az 
objektum állapotától függnek. Az állapotot általában egy vagy több felsoroló állandó 
jelöli. Számos művelet ugyanazt a feltételes szerkezetet használja. Az Állapot minta 
a feltétel minden ágát külön osztályba helyezi, így az objektum állapotát is önálló ob- 
jektumként kezelhetjük, amely a többi objektumtól függetlenül módosítható. 


Szerkezet 






— 
állapot-5.kezelf) 
KonkrétÁllapotA KonkrétÁllapotB 
Kezel() 


kezelt) 








Résztvevők 


e Környezet (TCPKapcsolaD) 
— Meghatározza az ügyfelek számára érdekes felületet. 
— Egy Konkrétállapot (ConcreteState) példányt tart fenn, amely meghatározza az ak- 
tuális állapotot. 
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e Állapot (TCPÁllapo0 
— Felületet határoz meg a Környezet (Context) egy adott állapotához kötődő visel- 
kedés egységbe zárásához. 
e  Konkrétállapot alosztályok (TCPKapcsolódva, TCPFigyelő, TCPLezárva) 
— A Környezet egy-egy állapotához kapcsolódó viselkedést valósítják meg. 


Együttműködés 


e A Környezet az állapotfüggő kérelmek kezelését átruházza az aktuális Konkrét- 
Állapot objektumra. 

. A Környezet argumentumként átadhatja magát a kérelmet kezelő állapotobjektum- 
nak, így az tudomást szerezhet a környezetről, ha szükséges. 

. A Környezet az ügyfelek elsődleges felülete. Az ügyfelek Állapot objektumokkal be- 
állíthatják a környezetet, ezután nem kell közvetlenül foglalkozniuk az állapotobjek- 
tumokkal. 

e Az állapotok sorrendjét, illetve az azt befolyásoló körülményeket a Környezet, illetve 
a Konkrétállapot alosztályok is meghatározhatják. 


Következmények 


Az Állapot tervezési minta előnyei és hátrányai a következők: 


1. Meghatározza és elkülöníti az egyes állapotokhoz tartozó viselkedéseket. Az Állapot 
mintában az egy adott állapothoz tartozó valamennyi művelet egyetlen objektumba 
kerül. Miután minden állapotfüggő kód egy Állapot alosztályban található, új alosz- 
tályok készítésével könnyen vehetünk fel új állapotokat és átmeneteket. 

Egy másik megoldás, ha a belső állapotok meghatározására adatértékeket haszná- 
lunk, amelyeket a Környezet műveletei ellenőriznek. Ekkor azonban több egyforma 
feltételes vagy elágazó utasítást kapunk, amelyek a Környezet megvalósításában 
szétszórva helyzekednek el, így egy új állapot hozzáadása számos művelet módosí- 
tását igényelheti, ami megnehezíti a kód karbantartását. 

Az Állapot mintával az említett probléma elkerülhető, viszont éppen a minta miatt 
beleütközhetünk egy másikba. Az, hogy a minta a különböző állapotokhoz tartozó 
viselkedéseket több Állapot alosztályba osztja el, növeli az osztályok számát, így 
a kód kevésbé lesz tömör, mintha egyetlen osztályt használnánk. Az elosztás akkor 
hasznos, ha sok-sok állapotunk van, amelyek másképp nagy méretű feltételes utasí- 
tásokat tennének szükségessé. 

A hosszú eljárásokhoz hasonlóan a hosszú feltételes utasítások sem kívánatosak. 
Tömbszerűek, rontják a kód átláthatóságát, így nehezen módosíthatók vagy bővíthe- 
tők. Az Állapot minta jobb megoldást nyújt az állapotfüggő kód szervezésére. Az ál- 
lapotátmeneteket vezérlő logika ebben a mintában nem monolitikus if vagy 
switch utasításokban található, hanem eloszlik az Állapot alosztályok között. Azzal, 
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hogy minden állapotátmenetet és műveletet egy osztályba tokozunk, a működési ál- 
lapotot egy teljes értékű objektum szintjére emeljük, ami világossá teszi a kód szer- 
kezetét és célját. 

Világossá teszi az állapotátmeneteket. Ha egy objektum az aktuális állapotát kizáró- 
lag belső adatértékekkel fejezi ki, állapotátmeneteinek nem lesz kifejezett ábrázolá- 
sa; azok csupán egyes változók értékadásaiban jelennek meg. Azzal, hogy az egyes 
állapotokhoz önálló objektumokat vezetünk be, egyértelműbbé tesszük az átmene- 
teket. 

Emellett az Állapot objektumok védelmet nyújtanak a környezetnek a következetlen 
belső állapotok ellen, hiszen a Környezet szemszögéből az állapotátmenetek atomi- 
ak — nem több, hanem egyetlen változó (a Környezet Állapot objektúmváltozója) ér- 
tékének módosításával mennek végbe [dCLF93]. 


. Az állapotobjektumok megoszthatók. Ha az állapotobjektumoknak nincsenek pél- 


dányváltozói (vagyis az általuk ábrázolt állapotot teljes mértékben a típusuk kódol- 
ja), a környezetek közösen is használhatják őket. Az állapotok ilyen megosztott 
használata lényegében a Pehelysúlyú minta (lásd az előző fejezetben) alkalmazása, 
ahol belső állapot nincs, csak viselkedés. 


Megvalósítás 


Az Állapot tervezési minta megvalósításával kapcsolatban a következőkre kell figyelni: 


1. Ki határozza meg az állapotátmeneteket? A minta nem ad útmutatást arra nézve, 


hogy melyik résztvevőnek kell meghatároznia az állapotátmenetek követelményeit. 
Ha a követelmények kötöttek, megvalósításuk teljes egészében történhet a Környe- 
zet objektumban. Mindazonáltal általában rugalmasabb és helyesebb megoldás, ha 
az Állapot alosztályokra bízzuk, hogy maguk határozzák meg, melyik állapot követ- 
heti őket, és milyen körülmények között. Ehhez a Környezetet ki kell bővítenünk 
egy felülettel, amely lehetővé teszi az állapotobjektumok számára, hogy a Környezet 
állapotát közvetlenül ők állítsák be. 

Az átmenetet vezérlő logika eme felosztása egyszerűbbé teszi a logika új Állapot al- 
osztályokkal történő bővítését vagy módosítását, hátránya viszont, hogy az állapot- 
objektumok legalább egy társukat ismerni fogják, ami megvalósítási függőségeket 
okoz az alosztályok között. 


. Egy táblázat alapú alternatíva. A Cs: Programming Style ICar92] című könyvben 


Cargill az állapotfüggő kód szervezésének egy másik módját írja le: táblázatokat 
használ a bemenetek és állapotátmenetek egymáshoz rendelésére. Az egyes állapo- 
tokhoz tartozó táblázatok minden lehetséges bemenetet egy következő állapothoz 
rendelnek, amelynek révén a feltételes kódot (és az Állapot minta esetében a virtuá- 
lis függvényekeD egy táblázatban való kereséssé alakítjuk. 
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A táblázatok legfőbb előnye a szabályosság; az átmenet követelményeit adatok, és 
nem programkód módosításával változtathatjuk meg. A megoldásnak természetesen 
vannak hátrányai is: 

s A táblázatban való keresés általában kevésbé hatékony, mint egy (virtuális) függ- 
vényhívás. 

s Az átmenet logikájának egységes, táblázatos formába rendezése homályossá, ne- 
hezen átláthatóvá teszi az átmenet-követelményeket. 

s Többnyire nehéz műveleteket adni az állapotátmenetekhez. A táblázatos megköze- 
lítés meghatározza az állapotokat és átmeneteiket, de ahhoz, hogy az átmeneteknél 
különféle számítási műveleteket végezhessünk, a megoldást ki kell bővítenünk. 

A táblázat alapú állapotautomaták és az Állapot tervezési minta közötti legfontosabb 
különbség a következőképpen foglalható össze: az Állapot minta az állapotfüggő vi- 
selkedést modellezi, míg a táblázatos megközelítés az állapotátmenetek meghatáro- 
Zására összpontosít. 
. Az Állapot objektumok létrehozása és megsemmisítése. A megvalósítás során gyako- 
ri, hogy választás elé kerülünk: csak akkor hozzuk létre az állapotobjektumokat, 
amikor szükség van rájuk, és utána semmisítsük meg őket (1), vagy készítsük el őket 
előre, és soha ne pusztítsuk el (2)? 
Az első lehetőséget akkor célszerű választani, ha a futásidőben beálló állapotokat 
nem ismerjük előre, és a környezet állapota nem változik gyakran. Így elkerülhetjük 
olyan objektumok létrehozását, amelyeket később nem is használunk, ami fontos, 
ha az állapotobjektumok sok információt tárolnak. A második lehetőség mellett ak- 
kor célszerű dönteni, ha az állapotváltozások gyorsan követik egymást. Ilyenkor 
nyilván el szeretnénk kerülni az állapotok megsemmisítését, hiszen rövidesen újra 
szükség lehet rájuk. Ha ezt a megoldást választjuk, a példányosítás költségeit egy- 
szer, előre kell csak megfizetnünk, a megsemmisítés pedig egyáltalán nem jár költsé- 
gekkel. Mindazonáltal ez a megközelítés kényelmetlen lehet, mert a környezetnek 
minden lehetséges állapotra hivatkozást kell fenntartania. 
. Dinamikus öröklés használata. Egy adott kérelemhez tartozó viselkedést elvileg 
módosíthatnánk úgy, hogy az objektum osztályát futásidőben megváltoztatjuk, de ez 
a legtöbb objektumközpontú programozási nyelvben nem lehetséges. A kivételt 
a Self [US87] és más átruházás alapú nyelvek jelentik, amelyek biztosítanak ilyen le- 
hetőséget, és ezáltal közvetlenül támogatják az Állapot tervezési mintát. A Self objek- 
tumai a dinamikus öröklés egy formáját azzal érik el, hogy átruházhatnak művelete- 
ket más objektumokra. A megbízott futásidejű megváltoztatása módosítja az öröklési 
szerkezetet; e megoldással az objektumok módosíthatják viselkedésüket, és vég- 
eredményben osztályukat. 
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Példakód 


A következő példa a Feladat részben leírt TCP kapcsolat C:- kódja; egyben a TCP proto- 
koll egyszerűsített változata. (Egyszerűsített, mert nem írja le a teljes protokollt, illetve 
a TCP kapcsolatok valamennyi állapotát." 


Először is, meghatározzuk a TCPConnection (TCPKapcsolat) osztályt, amely az adatátvi- 
tel felületét biztosítja, illetve az állapotváltoztatási kérelmeket kezeli. 


class TCPOCctetStream; 
class TCPState; 


class TCPConnection ( 
public: 
TcPConnection() ; 


void ActiveOpen( ) ; 
void PassiveOpen( ) ; 
void Close(); 

void Send(); 

void Acknowledget( ) ; 
void Synchronize( ) ; 


void ProcessOctet (TCPOCctetStreamt ) ; 
private: 

friend class TCPState; 

void ChangeState(TCPStatet) ; 
private: 

TCPStatet state; 
13 


A TcPConnection a TCPState (TCPÁllapot) osztály egy példányáta. state tagváltozó- 
ban tárolja. A TCPState osztály lemásolja a TCPConnection állapotmódosító felületét. 
Műveletei paraméterként egy TCPConnection példányt kapnak, így az osztály hozzáfér- 
het a TcPConnection adataihoz, és megváltoztathatja a kapcsolat állapotát. 


class TCPState ( 
public: 
virtual void Transmit(TCPConnectiont, TCPOctetStreamt) ; 
virtual void ActiveOpen(TCPConnection?t ) ; 
virtual void PassiveOpen(TCPConnectiont ) ; 
virtual void Close(TCPConnectiont ) ; 
virtual void Synchronize(TCPConnectiont ) ; 
virtual void Acknowledge ( TCPConnectiont ) ; 
virtual void Send(TCPConnection? ) ; 
protected: 
void ChangeState(TCPConnectiont, TCPStater); 
1; 





5 A példa a Lynch és Rose [LR93] által leírt TCP kapcsolati protokollon alapul. 
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A TcPConnection minden állapotfüggő kérelmet state TCPState példányára ruház 
át. A TCPConnection egy másik műveletet is biztosít, amely ezt a változót egy új TCP- 
State-re állítja. A TePConnection konstruktora az objektumnak a (később meghatáro- 
Zott) TcPClosed (TCPLezárva) állapotot adja kezdőértékül. 


TcPConnection: : TCPConnection () ( 
.State - TCPClosed::Instance( ) ; 
) 


void TCPConnection: : hangeState (TCPStater s) ( 
-state - s; 
kj 


void TCPConnection: :ActiveOpen () ( 
.Sstate-sActiveOpení(this) ; 
) 


void TCPConnection: :PassiveOpen () ( 
.State-sPassiveOpeníthis) ; 


) 


void TCPConnection::Close () ( 
.Sstate-sClose(this); 
) 


void TCPConnection: :Acknowledge () ( 
.SsState-sAcknowledge (this) ; 
) 


void TCPConnection: : Synchronize () ( 
.State-sSynchronizeí(this) ; 
) 


A TcPState tartalmazza a rá ruházott valamennyi kérelem teljesítéséhez szükséges alapér- 
telmezett viselkedés megvalósítását. Emellett a TCPConnection állapotát is képes megvál- 
toztatni, a Cnangestate (Változtatállapot) művelettel. A TCPState-eta TCPConnection 
barátjaként vezetjük be, így kivételezett hozzáférést kap ehhez a művelethez. 


void TCPState::Transmit (TCPConnectiont, TCPOctetStreamt) () 
void TCPState::ActiveOpen (TCPConnectionr) () 

void TCPState::PassiveOpen (TCPConnection"t) () 

void TCPState::Close (TCPConnectiont) () 

void TCPState::Synchronize (TCPConnection?Y) () 


void TCPState::ChangeState (TCPConnectiont t, TCPStater s) ( 
-t-:ChangeState(s) ; 
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A TcpState alosztályai állapotfüggő viselkedést valósítanak meg. A TCP kapcsolat számos 
állapotot vehet fel — Kapcsolódva, Figyelő, Lezárva stb. -, és mindegyikhez egy-egy 
TcpState alosztály tartozik. Ezek közül hármat tárgyalunk részletesen: a TCPEstab- 
lished (TCPKapcsolódva), a TCPListen (TCPFigyelő), illetve a TEPCLlosed (TCPLe- 
Zárva) osztályokat. 


class TCPEstablished : public TCPState ( 
public: 
static TCPStatet Instance(); 


virtual void Transmit ( TCPConnectiont, TCPOCctetStreamt) ; 
virtual void Close(TCPConnectiont ) ; 
); 


class TCPListen : public TCPState ( 
public: 
static TCPStater Instance(); 


virtual void Send(TCPConnectiont ) ; 
Pasa 
1; 


class TCPClosed : public TCPState ( 
public: 
static TCPStatetr Instance(); 


virtual void ActiveOpen( TCPConnectiont ) ; 
virtual void PassiveOpen( TCPConnection?t ) ; 
Eisas 

hi 


A TcCpState alosztályok helyi állapotinformációt nem tartanak fenn, így megoszthatók, és 


mindegyikből csak egy példányra van szükség. Az egyedi példányokat a statikus Instance 
(Példány) művelettel szerezzük meg." 


Az egyes TCPState alosztályok az állapothoz tartozó érvényes kérelmek állapotfüggő vi- 
selkedését valósítják meg: 


void TCPClosed::ActiveOpen (TCPConnectiont t) ( 
// SYN küldése, SYN, ACK stb. fogadása 


ChangeState(t, TCPEstablished::Instance( ) ) ; 
j 


void TCPClosed::PassiveOpen (TCPConnectionr t) ( 
ChangeState(t, TCPListen: :Instance( )) ; 
bi 


? Ennek révén a TCPState alosztályok az Egyke tervezési mintát követik. (Lásd az előző fejezetet.) 
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void TCPEstablished::Close (TCPConnectionr t) ( 
// FIN küldése, a FIN nyugtázásának (ACK) fogadása 


ChangeState(t, TCPListen::Instance()); 
J 


void TCPEstablished::Transmit ( 
TcPConnectiont t, TCPOctetStreamt o 
; A 
t-sProcessOctet (0) ; 


) 


void TCPListen::Send (TCPConnectiont t) ( 
// SYN küldése, SYN, ACK stb. fogadása 


ChangeState(t, TCPEstablished: :Instance( ) ) ; 


Az állapothoz kapcsolódó munka elvégzése után ezek a műveletek a CnangeState meg- 
hívásával megváltoztatják a TcPConnection állapotát. Maga a TCPConnection semmit 
sem tud a TCP kapcsolati protokollról; az állapotátmeneteket és TCP műveleteket 
a TcPState alosztályok határozzák meg. 


Ismert felhasználások 


Az Állapot mintát és alkalmazását a TCP kapcsolati protokollokra Johnson és Zweig írták le 
[7911]. 


A legtöbb népszerű interaktív rajzolóprogram , eszközöket" biztosít a közvetlen művelet- 
végzéshez, például egy vonalrajzoló eszköz segítségével a vonal pusztán kattintással és hú- 
zással megrajzolható, egy kijelölő eszközzel pedig ugyanígy alakzatokat jelölhetünk ki. 
Az eszközök általában egy palettán kapnak helyet, ahol választhatunk közülük. A felhasz- 
náló úgy gondol rá, mintha felvenne egy eszközt és használatba venné, pedig a valóság az, 
hogy a szerkesztőprogram viselkedése változik meg a kijelölt eszköznek megfelelően. 
Ha egy rajzoló eszköz aktív, alakzatokat hozhatunk létre, ha egy kijelölő, akkor kijelölhe- 
tünk, és így tovább. A viselkedés megváltoztatása a választott eszköznek megfelelően az 
Állapot minta segítségével lehetséges. 


Meghatározhatunk egy elvont Eszköz (Tool) osztályt, amelyből alosztályokat származtatva 
megvalósíthatjuk az egyes eszközöknek megfelelő viselkedéseket. A program nyomon köve- 
ti, melyik az aktuális Eszköz objektum, és a kérelmeket hozzá irányítja. Ha a felhasználó má- 
sik eszközt választ, az objektum kicserélődik, és így a program viselkedése is megváltozik. 


Ezt a megoldást alkalmazza mind a HotDraw [Joh92], mind a Unidraw [VL90] rajzoló keret- 
rendszer, és lehetővé teszik a felhasználónak, hogy könnyedén készítsen új eszközöket. 
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A HotDraw-ban a DrawingController (RajzVezérlő) osztály továbbítja a kérelmeket az aktu- 
ális Tool objektumnak, míg a Unidraw megfelelő osztályai a Viewer (Figyelő) és a Tool. 
Az alábbi osztálydiagram a Tool és a DrawingController felületek vázlatát mutatja: 












DrawingController szerént ől 














MousePressed() 
ProcessKeyboard() 
Initialize() 


HandleMousePress() 
HandleMouseRtelease() 
HandleCharacter() 
GetCursor() 

Activate() 


SelectionTool 


Coplien [Cop92] Envelope-Letter (boríték-levél) megoldása is hasonló az Állapot mintához, 
és azt teszi lehetővé, hogy egy objektum osztályát futásidőben megváltoztathassuk. Az Álla- 
pot minta ennél rögzítettebb, és arra összpontosít, hogyan kezelhetünk egy objektumot, 
amelynek viselkedése az állapotától függ. 


Kapcsolódó minták 
A Pehelysúlyú minta megmutatja, mikor és hogyan oszthatók meg az állapotobjektumok. 


Az állapotobjektumok gyakran az Egyke mintát követik. 


Mdlllllmee 


Stratégia 
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Stratégia 


Viselkedési objektumminta 


Cél 


Algoritmus-család meghatározása, melyben az algoritmusokat egyenként egységbe zárjuk 
és egymással felcserélhetővé tesszük. E módszer révén az algoritmus az ügyféltől függetle- 
nül módosítható. 


Egyéb nevek 


Strategy, Policy 


Feladat 


Szövegfolyamok sorokra tördelésére számos algoritmus létezik, de ezek ,bedrótozása? 
azon osztályokba, amelyeknek szükségük van rájuk, több okból sem kívánatos: 


s A sortörést igénylő ügyfelek túl naggyá, bonyolulttá és nehezen karbantarthatóvá 
válhatnak, ha tartalmazzák a sortörő kódot is, különösen ha több sortörő algoritmust 
is támogatnak. 

s A különböző algoritmusokra különböző helyzetekben lehet szükség. Több sortörő 
algoritmust nem célszerű támogatni, ha nem használjuk mindegyiket. 

e Nehéz új algoritmusokat felvenni, illetve a meglevőket módosítani, ha a sortörő kód 
az ügyfél szerves része. 


A fenti gondokat úgy orvosolhatjuk, ha az egyes sortörő algoritmusokat egységbe záró osz- 
tályokat határozunk meg. Az így egységbe zárt algoritmusokat nevezzük stratégiáknak. 





Összetétel 


Javít0) 


da Tömbösszeállító 
! Összeállítí) Összeállítt) Összeéllít() 
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Tegyük fel, hogy egy Összetétel (Composition) nevű osztály felelős egy szövegnézőben meg- 
jelenített szöveg sortöréseinek kezeléséért és frissítéséért. A sortörő stratégiákat nem ez az 
osztály valósítja meg, hanem külön-külön az elvont Összeállító (Compositor) osztály alosztá- 


lyai. Tehát az Összeállító alosztályokban különböző stratégiák megvalósításai találhatók: 


e Az Egyszerűösszeállító (SimpleCompositor) egy egyszerű stratégiát nyújt, amely egy- 
szerre egy sortörést határoz meg. 

e A TeXösszeállító (TeXCompositor) a TeX algoritmust valósítja meg a sortörések meg- 
keresése céljából. Ez a stratégia általános teljesítményfokozásra törekszik, így egy- 
szerre mindig több sort, egy bekezdést vizsgál. 

e A Tömbösszeállító C(ArrayCompositor) olyan stratégiát valósít meg, ami úgy töri meg 
a sorokat, hogy azokban egyenlő számú elem legyen. Ez például egy ikongyűjte- 
mény sorokra tördelésénél lehet hasznos. 


Az Összetétel objektumok hivatkozást tárolnak az Összeállító objektumokra. Amikor egy 
Összetétel újraformázza a szöveget, ezt a feladatot Összeállító objektumának továbbítja. 
Az Összetétel ügyfele úgy határozza meg, melyik objektumot kell használni, hogy a kívánt 
Összeállítót az Összetételbe telepíti. 


Alkalmazhatóság 


A Stratégia tervezési minta használata az alábbi esetekben célszerű: 


e Számos, kapcsolatban álló osztály csak a viselkedésében különbözik egymástól. 
A stratégiák lehetővé teszik, hogy egy osztályhoz több közül egy adott viselkedést 
rendeljünk. 

e Egy algoritmus több változatára van szükségünk, például különböző algoritmusokat 
határozunk meg aszerint, hogy az idő vagy a tárhely a fontosabb. A stratégiák jó 
szolgálatot tehetnek, ha a különböző változatok megvalósításai az algoritmusok osz- 
tályhierarchiáját alkotják (HO87]. 

e Egy algoritmus olyan adatokat használ, amelyekről az ügyfeleknek nem szabad tud- 
niuk. A Stratégia minta alkalmazásával elkerülhető az összetett, algoritmusfüggő 
adatszerkezetek felfedése. 

s Egy osztály többféle viselkedést határoz meg, és ezek műveleteiben többágú feltéte- 
les utasításokként jelentkeznek. A feltételágak helyett használjunk önálló stratégia- 
osztályokat. 


Stratégia 
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Szerkezet 







Környezet 


örmyezetFelület() 


hí 





KonkrétStratégiaB KonkrétStratégiaC 





Algorítmusfelületí) AlgoritmusfFelület() AlgoritmusfFelületi) 





Résztvevők 


s Stratégia (Összeállító) 

-— Közös felületet határoz meg a támogatott algoritmusok számára. A Környezet 
(Context) ezt a felületet használja a KonkrétStratégia (ConcreteStrategy) által meg- 
határozott algoritmus meghívására. 

e  KonkrétStratégia (Egyszerűösszeállító, TeXÖsszeállító, TömbÖsszeállító) 

— Megvalósítják az algoritmust a Stratégia felület segítségével. 

e Környezet (Összetétel) 

— Egy KonkrétStratégia objektum állítja be. 

— Hivatkozást tart fenn egy Stratégia objektumra. 

— Meghatározhat egy felületet, amelyen keresztül a Stratégia hozzáférhet a művele- 
teihez. 


Együttműködés 


s  AStratégia és a Környezet objektumok együtt valósítják meg a választott algoritmust. 
A környezet minden, az algoritmus által igényelt adatot átadhat a stratégiának, ami- 
kor az algoritmus meghívására sor kerül, de önmagát is átadhatja argumentumként 
a Stratégia műveleteinek, így a stratégia szükség esetén visszahívhatja a környezetet, 

e A környezet az ügyfeleitől érkező kérelmeket a hozzá tartozó stratégiához továbbít- 
ja. Az ügyfelek általában létrehoznak egy KonkrétStratégia objektumot, amelyet át- 
adnak a környezetnek; ezt követően kizárólag a környezettel tartanak kapcsolatot. 
Az ügyfél számára többnyire KonkrétStratégia osztályok egész családja áll rendelke- 
zésre, amelyből választhat. 
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Következmények 


A Stratégia minta előnyei és hátrányai a következők: 


1. A rokon algoritmusokból családok alkothatók. A Stratégia osztályok hierarchiája algo- 


ritmusok, illetve viselkedések családját alkotja, amelyet a környezetek újrahasznosít- 
hatnak. A minden algoritmusban jelen levő szolgáltatásokat örökléssel biztosíthatjuk. 


. Alternatívát nyújt az alosztályok létrehozásával szemben. Több algoritmust, illetve 


viselkedést örökléssel is támogathatunk, ha egy környezetosztályból közvetlenül 
származtatunk különböző viselkedéseket megvalósító alosztályokat. Ez azonban 
,bedrótozza" a viselkedést a Környezetbe, az algoritmus megvalósításának keverése 
a környezetével pedig nehezíti a Környezet kódjának megértését, karbantartását, il- 
letve bővítését. Emellett az algoritmus így dinamikusan nem változtatható, ráadásul 
számos rokon osztály jön létre, amelyeket csak az általuk alkalmazott algoritmus 
vagy viselkedés különböztet meg. Ha az algoritmust önálló Stratégia osztályokba 
zárjuk, a környezettel függetlenül cserélgethetjük azokat, ami megkönnyíti a módo- 


sítást és a bővítést. 


. A stratégiák szükségtelenné teszik a feltételes utasításokat. A Stratégia mintával ki- 


válthatjuk a kívánt viselkedés kiválasztására szolgáló feltételes utasításokat. Ha kü- 
lönböző viselkedéseket egyetlen osztályba tuszkolunk, nehezen kerülhetjük el 
a megfelelő kiválasztását célzó feltételes utasítások használatát. A viselkedés önálló 
Stratégia osztályokba zárása ezt is szükségtelenné teszi, 
Stratégiák nélkül például a szöveget sorokra tördelő kód valahogy így nézne ki: 
void Composition::Repair() ( 
switch ( breakingStrategy) ( 
case SimpleStrategy: 
ComposeWithSimpleCompositor ( ) ; 
break; 
case TeXStrategy: 
ComposeWithTeXCompositotr ( ) ; 
break; 
BZ aés 
) 
// az eredmények összeolvasztása a meglevő 
// összetétellel, ha szükséges 


) 


A Stratégia mintában a case utasításra nincs szükség, mert a sortörés feladatát egy 
Stratégia objektumra ruházzuk át: 
void Composition: :Repair () ( 
.compositor-5Compose ( ) ; 
// az eredmények összeolvasztása a meglevő 
// összetétellel, ha szükséges 
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Az olyan kód jelenléte, amelyben számos feltételes utasítás található, gyakran éppen 
arra utal, hogy érdemes lenne a Stratégia tervezési mintát alkalmazni. 

4. A megvalósítások választéka. A stratégiák ugyanannak a viselkedésnek különböző 
megvalósításait nyújtják, amelyek közül az ügyfél aszerint választhat, hogy idővel 
vagy tárhellyel kíván-e inkább fizetni. 

5. Az ügyfeleknek tudniuk kell a különböző stratégiákról. A minta egy lehetséges há- 
tulütője, hogy az ügyfélnek tudnia kell, miben különböznek az egyes stratégiák, mi- 
előtt kiválaszthatná a megfelelőt. Így a megvalósítás részleteinek felfedésére kerül- 
het sor, ezért a mintát csak akkor használjuk, ha az ügyfelek számára a viselkedések 
megkülönböztetése létfontosságú. 

6. A Stratégia és Környezet objektumok közötti kommunikációs többlet. A KonkrétStra- 
tégia osztályok mind használják a megosztott Strategy felületet, függetlenül attól, 
hogy az általuk megvalósított algoritmus egyszerű vagy összetett-e. Így valószínű, 
hogy egyes KonkrétsStratégia objektumok az e felületen keresztül kapott információk 
egy részét nem használják fel, sőt, a legegyszerűbbek talán semmit sem hasznosíta- 
nak belőle. Ez azt jelenti, hogy a környezet időnként olyan paramétereket hoz létre 
és lát el kezdőértékkel, amelyek használatára soha nem kerül sor. Ha ilyen probléma 
merül fel, szorosabb csatolásra van szükség a Stratégia és a Környezet között. 

7. Az objektumok nagy száma. A stratégiák növelik az alkalmazás objektumainak szá- 
mát, Ez a többletteher néha csökkenthető, ha a stratégiákat állapot nélküli objektu- 
mokként valósítjuk meg, amelyeket a környezetek megoszthatnak. Az állapotot ek- 
kor a környezet tartja számon, és a Stratégia objektumokhoz irányuló kérelmekben 
adja át. A megosztott stratégiák nem szabad, hogy a meghívások között állapotot tá- 
roljanak. A Pehelysúlyú tervezési minta ismertetésénél (4. fejezet) részletesebben 
tárgyaltuk e megközelítést. 


Megvalósítás 


A megvalósítás során a következőkre kell ügyelnünk: 


1. A Stratégia és Környezet felületek meghatározása. A Stratégia és Környezet felületek 
hatékony hozzáférést kell biztosítsanak a KonkrétStratégia objektumoknak bármely 
adathoz, amelyre azoknak szükségük van a környezettől, és viszont. 

2. Stratégiák mint sablonbaraméterek. A C4---ban a stratégiával rendelkező osztályok 
sablonokkal (template) állíthatók be. Ez a megoldás csak akkor kivitelezhető, ha (1) 
a stratégia fordításkor kiválasztható, és (2) futásidőben nem kell megváltoztatni. 
Ha ezek a feltételek fennállnak, a beállítandó osztályt (például a Context-e) sab- 
lonosztályként határozzuk meg, amelynek paramétere egy Strategy osztály: 

template cclass AStrategys 

class Context ( 
void Operation() ( theStrategy.DoAlgorithm(); ) 
PT sú 

private: 
AStrategy theStrategy; 

); 
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Az osztályt ezután példányosításkor egy Strategy osztállyal állítjuk be: 
class MyStrategy ( 
public: 
void DoAlgorithm( ) ; 
1; 


ContextcMyStrategy: aContext; 


Sablonok használata esetén nem kell elvont osztályt meghatároznunk, ami a Strategy 
felületét írja le, emellett a Sstrategy sablonparaméterként való alkalmazása azt is lehe- 
tővé teszi, hogy egy stratégiát statikusan kössünk a környezetéhez, ami növelheti a ha- 
tékonyságot. 

3. A Stratégia objektumok választhatóvá tétele. A Környezet osztály egyszerűsíthető, 
amennyiben van értelme annak, hogy ne legyen Stratégia objektuma. Ekkor a Környe- 
zet hozzáférés előtt ellenőrzi, hogy rendelkezik-e Stratégia objektummal; ha igen, a kör- 
nyezet a szokásos módon használatba veszi, ha nem, az alapértelmezett viselkedést kö- 
veti. A megközelítés előnye, hogy az ügyfeleknek egyáltalán nem kell törődniük a Stra- 
tegy objektumokkal, kivéve ha nem tetszik nekik az alapértelmezett viselkedés. 


Példakód 


Itt a Feladat részben bemutatott példa magasszintű kódját adjuk meg, ami az InterViews 
[LCI--92] Composition (Összetétel) és Compositor (Összeállító) osztályainak megvalósításán 
alapul. 


A Composition osztály Component (Elem) példányok gyűjteményét tartalmazza, amelyek 
a dokumentum szöveg- és grafikus elemeit jelölik. Az összetétel az elemobjektumokat egy, 
a sortörő stratégiát egységbe záró Compositor alosztály példányának segítségével sorokba 
rendezi. Minden elemhez tartozik egy természetes vagy alapméret (natural size), egy nyújt- 
hatósági (stretchability) és egy zsugoríthatósági (shrinkability) érték. A nyújthatósági érték 
azt adja meg, hogy az összetevő az alapméretéhez képest mennyire nőhet meg, a zsugorít- 
hatósági érték pedig azt, hogy mennyit zsugorodhat. Az összetétel átadja ezeket az értékeket 
egy összeállítónak, amely segítségükkel megállapítja a sortörések legkedvezőbb helyét. 
class Composition ( 
public: 
Composition(Compositort ) ; 
void Repair(); 


private: 
Compositort . compositor; 
Componentt . components; // az elemek listája 
int . componentCount ; // az elemek száma 
int . lineWidth; // az összetétel sorszélessége 
int . lineBreaks; // a sortörések helye az 


// elemekben 
int , lineCount; // a sorok száma 
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Amikor csak új elrendezésre van szükség, az összetétel megkéri összeállítóját, hogy állapít- 
sa meg a sortörések helyét. Három tömböt ad át neki, amelyek az elemek alapméretett, il- 
letve nyújthatósági és zsugoríthatósági értékeit tartalmazzák. Emellett átadja az elemek szá- 
mátis, a sor szélességét, illetve még egy tömböt, amelyet az összeállító a sortörések helyé- 
vel tölt majd fel. Az összeállító a sortörések kiszámított számát adja vissza. 


A Compositor felület lehetővé teszi az összetételnek, hogy minden szükséges adatot átad- 
jon az összeállítónak: 


class Compositor ( 
public: 
virtual int Compose( 
Coord natural[], Coord stretch[], Coord shrink[(]), 
int componentCount, int lineWidth, int breaks[] 
9 2 ÜZ 
protected: 
Compositor ( ) ; 
1; 


Észrevehetjük, hogy a Compositor elvont osztály, amelynek konkrét alosztályai határoz- 
zák meg a különböző sortörési stratégiákat. 


Az összetétel Repair (Javít) műveletében hívja meg összeállítóját. A Repair először feltöl- 
ti a tömböket az elemek alapméret, nyújthatóság és zsugoríthatóság értékeivel (aminek 
részleteit a rövidség kedvéért itt kihagyjuk), majd az összeállítótól elkéri a sortöréseket (a 
töréseket is mellőztük), végül azoknak megfelelően elrendezi az elemeket: 


void Composition: :Repair () ( 
Coordt natural; 
Coordt stretchability; 
CoordY shrinkability; 
int componentCount; 
intt breaks; 


// a tömbök előkészítése a kívánt méretekkel 
E s vs 


// a törések helyének megállapítása 

int breakCount; 

breakCount - . compositor-5Compose ( 
natural, stretchability, shrinkability, 
componentCount, . lineWidth, breaks 


); 


// az elemek elhelyezése a töréseknek megfelelően 
EV. si 
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Most vessünk egy pillantást a Compositor alosztályaira. A SimplecCompositor (Egysze- 
rűÖsszeállító) soronként megvizsgálja az elemeket, hogy megállapítsa, hová kerüljenek 
a törések: 


class SimpleCompositor : public Compositor ( 
putlies 
SimpleCompositor ( ) ; 


virtual int Compose( 
Coord natural[], Coord stretch[], Coord shrink[], 
int componentCount, int lineWidth, int breaks[] 


A TeXCompositor (TeXÖsszeállító) stratégiája általánosabb. Egyszerre egy bekezdést vizs- 
gál, figyelembe véve az elemek méretét és nyújthatóságát, emellett az elemek közötti 
üreshelyek lehető legkevesebbre csökkentésével egyenletes , színt" is próbál adni a bekez- 
désnek. 


class TeXCompositor : public Compositor ( 
public: 
TeXCompositor ( ) ; 


virtual int Compose( 
Coord natural[], Coord stretch[], Coord shrink(], 
int componentCount, int lineWidth, int breaks[] 


Az ArrayCompositor (TömböÖsszeállító) az elemeket szabályos közönként sorokra tördeli. 


class ArrayCompositor : public Compositor ( 
public: 
ArrayCompositor(int interval); 


virtual int Compose( 


Coord natural[], Coord stretch[], Coord shrink([], 
int componentCount, int lineWidth, int breaks([(] 


Stratégia 


325 





A fenti osztályok nem használnak fel minden információt, amit a compose-ban (Összeállíd 
kaptak. A SimpleCompositor figyelmen kívül hagyja az összetevők nyújthatóságát, csak 
alapszélességükkel számol. A TexCompositor minden átadott információt hasznosít, az 
ArrayCompositor viszont mindent figyelmen kívül hagy. 


A Composition úgy példányosítható, hogy átadjuk neki a használni kívánt összeállítót: 


Compositiont guick new Composition(new SimpleCompositor) ; 
CompositionY slick new Composition(new TeXCompositor) ; 
Compositiont iconic - new Composition(new ArrayCompositor(100) ); 


A Compositor felületét gondosan kell megtervezni, hogy minden elrendezési algoritmust 
támogasson, amit csak az alosztályok megvalósíthatnak. Ez azért fontos, mert nyilván nem 
szeretnénk minden új alosztály létrehozásakor megváltoztatni a felületet, ami a meglevő al- 
osztályok megváltoztatását is maga után vonná. Általánosságban azt mondhatjuk, a Straté- 
gia és Környezet felületek határozzák meg, hogy a tervezési minta mennyire éri el a célját. 


Ismert felhasználások 


Mind az ET--- (WGM88], mind az InterViews stratégiákat használ a fent leírt különböző sor- 
törési algoritmusok egységbe zárására. 


A fordítói kódoptimalizáló RTL rendszerben [JML92] stratégiák határozzák meg a különbö- 
ző regiszterfoglalási sémákat (RegisterAllocator), illetve utasításkészlet-ütemező irányelve- 
ket (RISCscheduler, CISCscheduler). Ezzel az optimalizáló rugalmasabban alkalmazkodhat 
a különféle számítógép-architektúrákhoz. 


Az ETt4t SwapsManager számítómotor-keretrendszer különböző pénzügyi eszközök árait 
számítja ki (EG92]. Kulcsfogalmai az Instrument (Eszköz) és a YieldCurve (Hozamgörbe), 
Az egyes eszközöket az Instrument alosztályaiként valósították meg. A YieldCurve azokat 
a tényezőket számítja ki, amelyek a jövőbeni pénzforgalom jelenlegi értékét határozzák 
meg. Mindkét osztály Stratégia osztályokra ruház át bizonyos feladatokat. A keretrendszer 
KonkrétStratégia osztályok családjával számítja ki a pénzáramlást, a devizaárfolyamokat, és 
a leszámítolási tényezőket. Új számítómotorokat úgy készíthetünk, ha az Instrument és 
YieldCurve osztályokat más KonkrétStratégia objektumokkal állítjuk be. Ez a megközelítés 
támogatja a meglevő Stratégia-megvalósítások keverését és illesztését, valamint újak meg- 
határozását is. 


A Booch komponensek [BV90] a stratégiákat sablonargumentumként használják. A Booch 
gyűjteményosztályok háromféle memóriafoglalási stratégiát támogatnak: kezelt (foglalás 
gyűjtőtárból), ellenőrzött (a foglalást és felszabadítást zárak védik), illetve kezeletlen (szok- 
ványos memóriafoglalás). A stratégiát példányosításkor sablonargumentumként adjuk át 
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a gyűjteményosztálynak, a kezeletlen stratégiát alkalmazó UnboundedCollection (Nem- 
korlátosGyűjtemény) példányosítása például az UnboundedCollectioncMyItem- 
Type" , Unmanaged;5 formában történik. 


A RApp rendszer integrált áramkörök elrendezését szolgálja (GA89, AG90]. A RApp-nak kell 
lefektetnie és összekötnie az áramkör alrendszereit összekapcsoló vezetékeket. A kapcsoló 
algoritmusok az elvont Router osztály alosztályai, amely maga egy stratégiaosztály. 


A Borland ObjectWindows-a [Bor94] a párbeszédablakokban használ stratégiákat, annak el- 
lenőrzésére, hogy a felhasználó érvényes adatokat adott-e meg. A számoknak például egy 
meghatározott tartományban kell lenniük, a számbeviteli mezők pedig csak számjegyeket fo- 
gadhatnak el. A karakterláncok érvényességének ellenőrzése táblázatos keresést igényelhet. 


Az ObjectWindows Validator (Érvényesítő) objektumokkal zárja egységbe az érvényesítő 
stratégiákat. Az érvényesítők a stratégiaobjektumoknak felelnek meg. Az adatbeviteli me- 
zők az érvényesítő stratégiával egy választható Validator objektumot bíznak meg. Az ügyfél 
igény esetén érvényesítőket kapcsol a mezőkhöz (a válaszható stratégia példája); amikor 
pedig a párbeszédablakot bezárják, a beviteli mezők felkérik érvényesítőiket az adatok el- 
lenőrzésére,. A leggyakrabban előforduló ellenőrzésekhez az osztálykönyvtár biztosítja az 
érvényesítőket, a számok esetében például a RangeValidator-t (Tartományellenőrző). Új, 
ügyfélfüggő érvényesítő stratégiákat is könnyen meghatározhatunk; ehhez elég a Validator 
osztályból új alosztályokat származtatnunk. 


Kapcsolódó minták 


Pehelysúlyú: a stratégiaobjektumok általában jól illeszkednek a Pehelysúlyú mintába. 


Sablonfüggvény 
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Sablonfüggvény 


Viselkedési osztályminta 


Cél 


Egy adott művelet algoritmusának vázát elkészíteni, amelynek egyes lépéseit alosztályokra 
ruházzuk át. Így az alosztályok az algoritmus egyes lépéseit felülbírálhatják, anélkül, hogy 
az algoritmus szerkezete módosulna. 


Feladat 


Vegyünk egy alkalmazás-keretrendszert, amelyben találunk egy Alkalmazás (Application) 
és egy Dokumentum (Document) nevű osztályt. Az Alkalmazás osztály felel a ,külső" for- 
mátumban -— például fájlban — tárolt dokumentumok megnyitásáért, míg a Dokumentum 
objektum a dokumentum adatait ábrázolja, miután kiolvastuk azokat a fájlból. 


A keretrendszer segítségével épített alkalmazások egyedi igényeiknek megfelelően alosztályo- 
kat származtathatnak az Alkalmazás és Dokumentum osztályokból. Egy rajzolóprogram példá- 
ul meghatározhat egy RajzAlkalmazás (DrawApplication) és egy RajzDokumentum (Draw- 
DocumenD nevű alosztályt, egy táblázatkezelő egy TáblázatKezelőAlkalmazás (Spread- 
SheetApplication) és egy TáblázatkezelőDokumentum (SpreadSheetDocument) nevűt, és így 
tovább. 


NJ 
retum new SajátDokumentum 





Az elvont Alkalmazás osztály MegnyitDokumentum (OpenDocumen0) művelete határozza 
meg a dokumentumok megnyitására és olvasására szolgáló algoritmust: 
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void Application: : penDocument (const char! name) ( 
if (!CanopenDocument(name)) ( 
// a dokumentum nem nyitható meg 
return; 


) 
Documentt doc - DoCreateDocument ( ) ; 


if (doci 1 
.-docs-sAddDocument (doc) ; 
AboutToOpenDocument (doc) ; 
doc-50Open ( ) ; 
doc-sDoRead ( ) ; 


) 


Az OpenDocument a dokumentum megnyitásának minden lépését meghatározza. Ellenőr- 
zi, hogy a dokumentum megnyitható-e, létrehozza az alkalmazásra jellemző Dokumentum 
objektumot, hozzáadja a dokumentumok halmazához, és kiolvassa a dokumentumot 
(Document) a fájlból. 


Az ilyen műveleteket sablonfüggvényeknek hívjuk. A sablonfüggvény elvont műveletekkel 
határoz meg egy algoritmust, mely műveleteket az alosztályok felülbírálják, hogy elérjék 
a megfelelő viselkedést. Az Alkalmazás alosztályai az algoritmusnak a dokumentum meg- 
nyithatóságát ellenőrző (KépesMegnyitDokumentum, CanOpenDocumen1), illetve a Doku- 
mentum objektumot létrehozó (DoLétrehozDokumentum, DoCreateDocument) lépéseit 
határozzák meg, a Dokumentum. osztályok pedig a dokumentum olvasására szolgálót 
(DoOlvas, DoRead). A sablonfüggvény egy olyan műveletet is meghatároz, amely értesíti 
az Alkalmazás alosztályokat arról, hogy a dokumentum megnyitására készülünk (Készül- 
MegnyitDokumentum, AboutToOpenDocumen?), ha erre szükségük lenne. 


Azzal, hogy az algoritmus egyes lépéseit elvont műveletekkel határozza meg, a sablonfügg- 
vény rögzíti azok sorrendjét, de megengedi az Alkalmazás és Dokumentum alosztályok- 
nak, hogy a lépéseket egyedi igényeikhez igazítsák. 


Alkalmazhatóság 


A Sablonfüggvény tervezési minta alkalmazása az alábbi esetekben célszerű: 

e Egy algoritmus nem változó részeit egyszerre szeretnénk megvalósítani, míg a válto- 
zó viselkedés megvalósítását az alosztályokra hagynánk. 

e Az alosztályok közös viselkedését a kódkettőződés elkerülése végett közös osztályban 
kell rögzíteni. ( Refactoring to generalize", vagyis , újraépítés az általánosítás érdeké- j 
ben", lásd Opdyke és Johnson [0J93].) Ehhez először meg kell keresnünk az eltérése- 
ket a meglevő kódban, ezeket új műveletekbe kell helyeznünk, végül az eltérő kódot 
sablonfüggvénnyel kell helyettesítünk, ami az új műveletek valamelyikét hívja meg. 
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e Kézben szeretnénk tartani az alosztályok bővítését. Ha olyan sablonfüggvényt hatá- 
rozunk meg, amely adott pontokon , horog" (hook) műveleteket hív meg (lásd a Kö- 
vetkezmények részt), a bővítéseket ezekre a pontokra korlátozhatjuk. 


Szerkezet 





ElvontOsztály 


SablonFüggvényt) AlapMűvelet1() 
AlapMűvelet1() si 
AlapMűvelet2() AlapMűvelet2) 





KonkrétOsztály 


AlapMűvelet1() 
AlapMűvelet2() 





Résztvevők 


e  ElvontOsztály (Alkalmazás) 

— Elvont alapműveleteket határoz meg, amelyeket a konkrét alosztályok felülírnak, 
hogy megvalósítsák az algoritmus lépéseit. 

-— Sablonfüggvényt biztosít, amely meghatározza az algoritmus vázát. A sablonfügg- 
vény alapműveleteket és az ElvontOsztályban (AbstractClass) vagy más objektu- 
mokban meghatározott műveleteket is meghív. 

s  KonkrétOsztály (SajátAlkalmazás) 

— Megvalósítja az alapműveleteket, hogy végrehajthassa az algoritmus alosztályfüg- 

gő lépéseit. 





Együttműködés 


s A KonkrétOsztály (ConcreteClass) az ElvontOsztályra támaszkodik, amely az algorit- 
mus nem változó lépéseit valósítja meg. 


Következmények 


A sablonfüggvények alapvető fontosságúak a kód-újrahasznosításban. Különösen fontos 
szerepet töltenek be az osztálykönyvtárakban, hiszen a könyvtár osztályainak közös visel- 
kedését hivatottak leírni. 
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A sablonfüggvények alkalmazása fordított vezérlési szerkezetet erdményez, amire időnként 
a ,Hollywood elv" néven hivatkoznak (Ne hívjon minket — mi hívjuk magát.") ISwe85]. 
Ez arra utal, hogy a szülő osztály hívja az alosztály műveleteit, és nem fordítva. 


A sablonfüggvények az alábbi típusú műveleteket hívják meg: 


e konkrét műveletek (a KonkrétOsztályokon vagy az ügyfélosztályokon); 

s konkrét ElvontOsztály műveletek (azon műveletek, amelyek általánosságban hasz- 
nosak az alosztályok számára); 

e alapműveletek (vagyis az elvont műveletek); 

e gyártófüggvények (lásd a Gyártófüggvény mintát a 3. fejezetben); és 

e  horogműveletek (ezek biztosítják az alapértelmezett viselkedést, amelyet az alosztály- 
ok igényeiknek megfelelően kibővíthetnek; a horogművelet alapértelmezés szerint 
gyakran semmit nem csinál). 


Lényeges, hogy a sablonfüggvények meghatározzák, mely műveletek horgok (ezek esetleg 
felülbírálhatók) , és melyek elvont műveletek (ezeket felül ke// bírálni). Ahhoz, hogy egy al- 
osztály kész hatékonyan használhasson fel egy elvont osztályt, tudnia kell, mely műve- 
leteket kell felülírnia. 





Az alosztályok úgy bővíthetik ki a szülő egy műveletének viselkedését, hogy felülírják 
a műveletet, és kifejezetten meghívják a szülőműveletet: 


void DerivedClass::Operation () ( 
ParentClass: : Operation ( ) ; 
7/ a DerivedClass bővített művelete 


Sajnos az örökölt művelet meghívásáról könnyű megfeledkezni, de egy ilyen műveletet 
sablonfüggvénnyé is alakíthatunk, hogy a szülő felügyelhesse, hogyan bővítik ki alosztá- 
lyai. A megoldás lényege, hogy a szülő osztály sablonfüggvényéből meghívunk egy horog- 
műveletet, amelyet aztán az alosztályok felülbírálhatnak: 


void ParentClass::Operation () ( 
// a ParentClass viselkedése 
HookOperation( ) ; 

) 


A Hookoperat ion (HorogMűvelet) semmit nem csinál a szülő osztályban: 


void ParentClass::HookOperation () ( ) 
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Az alosztályok viszont a HookOperation-tt felülírva kibővítik annak viselkedését: 


void DerivedClass::HookOperation () ( 
// a származtatott osztály bővítése 
) 
Ed PH A 
Megvalósítás 


Három dolgot fontos megemlítenünk: 


1. A C44 hozzáférés-vezérlésének használata. A Cs4-ban a sablonfüggvények által 
meghívott alapműveleteket védett tagokként is bevezethetjük, így biztosíthatjuk, 
hogy csak a sablonfügggvény hívhassa meg azokat. A kötelezően felülírandó alap- 
műveleteket tisztán virtuálisként adjuk meg. Magát a sablonfüggvényt nem szabad 
felülírni, így az nem virtuális tagfüggvény lesz. 

2. Az alapműveletek számának a lehető legkisebbre csökkentése. A sablonfüggvények 
írásának egyik fontos célja az alosztályok által az algoritmus megvalósításához köte- 
lezően felülírandó alapműveletek számának csökkentése. Minél több műveletet kell 
felülbírálni, annál több az ügyfelek munkája. 

3. Az elnevezési rendszer. A felülírandó műveleteket könnyen azonosíthatjuk, ha ne- 
vük elé valamilyen közös előtagot teszünk. A Macintosh alkalmazások MacApp ke- 
retrendszere lApp89] például a sablonfüggvények neve elé a , Do" előtagot helyezi 
(DoCreateDocument, DoRead stb.). 


Példakód 


Az alábbi Cs példa azt mutatja, hogyan kényszeríthet egy szülő osztály egy invariánst (ál- 
landó állítás alosztályaira. A példa forrása a NeXT AppKit (Add94]. Vegyünk egy View 
(Nézet) nevű osztályt, amelynek segítségével a képernyőre rajzolhatunk. A View ragaszko- 
dik ahhoz, hogy alosztályai csak azután kezdhessék meg a rajzolást, hogy az ablak (view) 
megkapta a fókuszt. Ez bizonyos megjelenési tulajdonságok (színek, betűtípusok) megfele- 
lő állapotbeállítását vonja maga után. 


A beállításokat a Di splay (MegjeleníÜ sablonfüggvényre bízzuk. A Vi.ew két konkrét műve- 
letet határoz meg: a SetFocus (BeállítFókusz) beállítja, a ResetFocus (VisszaállítFókusz) 
pedig törli a rajzolási állapotot. A tényleges rajzolást a View DoDi splay horogművelete vég- 
zi. A Display a DoDisplay előtt meghívja a SetFocus-t, hogy beállítsa az állapotot, a vé- 
gén pedig meghívja a ResetFocust-t, hogy visszaálljon az eredeti helyzet. 


void View::Display () ( 
SetFocus(); 
DoDisplay() ; 
ResetFocus() ; 
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AZ invariáns fenntartásához a View ügyfelei mindig a Display-t hívják, alosztályai pedig 
a DoDisplay-t írják felül. 


A DoDisplay a View-ban semmit nem csinál: 


void View: :DoDisplay () ( ) 


Az alosztályok e művelet felülírásával határozzák meg egyedi rajzoló műveletüket: 


void MyView::DoDisplay () ( 
// az ablak tartalmának megjelenítése 


) 


Ismert felhasználások 


A sablonfüggvények alapvető jelentőségét mutatja, hogy szinte minden elvont osztályban 
megtalálhatók. Wirfs-Brock és szerzőtársai (WBWW90, WBJ90] remek áttekintést nyújtanak 
a sablonfüggvényekről. 


Kapcsolódó minták 


A sablonfüggvények gyakran támaszkodnak a Gyártófüggvény mintára. A Feladat részben 
szereplő DoCreateDocument, amelyet az OpenDocument sablonfüggvény hív meg, is 
gyártófüggvény. 


A sablonfüggvények öröklés révén változtatják az algoritmus egyes részeit, a Stratégia min- 
tában átruházás révén a teljes algoritmust kicserélhetjük. 
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Látogató 
Viselkedési objektumminta 


Cél 


Egy objektumszerkezet elemein végrehajtandó műveletet ábrázolni: a Látogató minta segít- 
ségével anélkül határozhatunk meg egy új műveletet, hogy a benne részt vevő elemek osz- 
tályát meg kellene változtatnunk. 


Feladat 


Vegyünk egy fordítóprogramot, ami a programokat elvont szintaxisfákként ábrázolja. Eze- 
ken ,statikus jelentéselemző" műveleteket kell végeznie, például ellenőriznie kell, hogy 
minden változót meghatároztunk-e, emellett pedig kódot is elő kell állítania. Ennek megfe- 
lelően szükségünk lesz típusellenőrző, kódoptimalizáló, vezérléselemző műveletekre, 
olyanra, ami ellenőrzi, hogy használatba vétel előtt adtunk-e értéket a változóknak, és így 
tovább. Az elvont szintaxisfát ezenkívül használhatnánk formázott kiíratásra, program-újra- 
szervezésre, kód-előállításra és különféle, a programmal kapcsolatos számításokra is. 


Az említett műveletek legtöbbjének másképpen kell kezelnie azokat a csomópontokat, 
amelyek értékadó utasításokat jelölnek, mint azokat, amelyek változókat vagy matematikai 
kifejezéseket ábrázolnak. Ezért külön osztályunk lesz az értékadásokhoz, egy másik a vál- 
tozók eléréséhez, egy harmadik a matematikai kifejezésekhez, és így tovább. A csomópont- 
osztályok halmaza természetesen az alkalmazott programozási nyelvtől függ, de nem kü- 
lönbözhet jelentősen. 





Csomópont 






ÉrtékadásCsomópont 





VáltozóHivCsomópont 





TípusEllenőriz() 
ElőállítKód() 
Formázvakiíri) 








A fenti diagram a Csomópont (Node) osztályhierarchia egy részét mutatja. A gond itt az, 
hogy az említett műveletek különféle csomópont-osztályokba való elosztása révén egy 
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olyan rendszer áll elő, amely nehezen átlátható, nehezen karbantartható, és módosítása is 
fáradságos. Zavaró, hogy a típusellenőrző kód keveredik a formázó vagy a vezérléselemző 
kóddal, arról nem is beszélve, hogy egy új művelet hozzáadása valószínűleg az összes osz- 
tály újrafordítását igényli. Jobb lenne, ha az új műveleteket külön vehetnénk fel, a csomó- 
pont-osztályok pedig függetlenek lennének az őket használó műveletektől. 


Mindkettő elérhető, ha az osztályokban található rokon műveleteket önálló objektumba, ú gy- 
nevezett látogatóba csomagoljuk, majd ezt adjuk át az elvont szintaxisfa elemeinek bejárás 
közben. Amikor egy elem , fogadja" (accept) a látogatót, kérelmet küld annak, ami az adott 
elem osztályát tartalmazza, illetve magát az elemet mint argumentumot. A látogató ezután 
végrehajtja az elemnek megfelelő műveletet, ami korábban az elem osztályában szerepelt. 


Például egy fordítóprogram, amely nem használ látogatókat, a TípusEllenőriz (TypeCheck) 
műveletet az elvont szintaxisfára meghívva végezhet típusellenőrzést egy eljáráson. Ekkor 
minden csomópont megvalósítja a TípusEllenőriz műveletet, azzal, hogy meghívja azt a cso- 
mópont elemeire (lásd az előző osztálydiagramon). Ha a fordító a típusellenőrzést látogatók se- 
gítségével végzi, létrehoz egy TípusEllenőrzőLátogató (TypeCheckingvVisitor) objektumot, és 
azt argumentumként használva a Fogad (Accept) műveletet hívja meg az elvont szintaxisfára. 
Ennél a megoldásnál a csomópontok a látogató visszahívásával a Fogad műveletet valósíi ják 
meg: az értékadó (assignment) csomópontok a LátogatÉrtékadás CVisitAssignment), a változó- 
hivatkozások a LátogatVáltozóHivatkozás (VisitVariableReference) művelet meghívásával. 
A korábban az ÉrtékadásCsomópont (AssignmentNode) osztályban levő TípusEllenőriz műve- 
let így a TípusEllenőrzőLátogatóra meghívott LátogatÉrtékadás művelet lesz. 





Ahhoz, hogy a látogatókkal ne csupán típusellenőrzést végezhessünk, szükségünk lesz az 
elvont szintaxisfa összes látogatójának elvont szülő osztályára (CsomópontlLátogató, 
NodeVisitor), amelynek minden csomópont osztály számára be kell vezetnie egy művele- 
tet. Egy programméreteket kiszámító alkalmazás ezután a CsomópontlLátogatóból származ- 
tathat új alosztályokat, nem lesz többé szükség a csomópont osztályokban alkalmazá függő 
kódra. A Látogató minta a programfordítási lépések műveleteit a nekik megfelelő Látogató 
objektumba zárja. 








w CsomópontLátogató 


Látogatértékadás(ÉrtékadásCsomópontj) 
LátogatvVáltozókHiv(VáltozókíívCsomópontj) 


l A ! 


TípusEllenőrzőlátogató j KódElőállítóLátogató 




















LátogatVáltozóHiv(VáltozóHívCsomópont) LátogatvVáltozóHiv(VáltozóHívCsomópont) 











LátogatéÉrtékadáslÉrtékadásCsomópont) J LátogatÉrtékadás(ÉrtékadásCsomópont) 
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Program 















ÉrtékadásCsomópont VáltozóHivCsomópont 











Fogad(CsomópontlLátogató v) § Fogad(CsomópontLátogató v) § 
1 1 
1 1 


v-olátogatértékadásíthis) sg v-oLátogatváltozóHivíthis) s; 


A Látogató mintában két osztályhierarchiát alakítunk ki: egyet az elemek számára, amelye- 
ken műveleteket végzünk (Csomópont hierarchia), és egy másikat az elemeken végrehaj- 
tandó műveleteket meghatározó látogatók számára (Csomópontlátogató hierarchia). Új 
műveletet a látogató osztályhierarchia új alosztállyal való bővítésével határozhatunk meg. 
Amíg a fordító által elfogadott nyelvtan nem változik (vagyis amíg nem kell új Csomópont 
alosztályokat felvennünk), az új szolgáltatások beépítéséhez elég új CsomópontlLátogató al- 
osztályokat létrehoznunk. 





Alkalmazhatóság 


A Látogató tervezési minta alkalmazása a következő esetekben célszerű: 


e Egy adott objektumszerkezet számos különböző felületű osztályt tartalmaz, és eze- 
ken az objektumokon olyan műveleteket szeretnénk végezni, amelyek a konkrét 
osztályoktól függnek. 

e Egy objektumszerkezet objektumain több önálló, egymással nem rokon műveletet 
kell végrehajtanunk, és nem akarjuk az osztályokat ,beszennyezni" e műveletekkel. 
A Látogató minta segítségével a rokon műveletek együtt tarthatók, ha közös osztály- 
ban határozzuk meg azokat. Ha egy objektumszerkezetet több alkalmazás közösen 
használ, mindig érdemes a műveleteket a Látogató mintával az őket ténylegesen 
igénylő alkalmazásokba helyezni. 

e Az adott objektumszerkezetet meghatározó osztályok ritkán változnak, de új műve- 
letekre gyakran van szükség. Az említett osztályok megváltoztatása az összes látoga- 
tó felületének módosítását igényli, ami valószínűleg költséges. Ha ezen osztályok 
gyakran változnak, érdemesebb a műveleteket beléjük helyezni. 
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Szerkezet 








Látogató j 
LátogatkonkrátElemA(konkrótElemA) 3 





LátogatkonkrétElemB(KonkrétElemB) 
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I Hit A 




















Konkrétlátogatót ] KonkrétLátogató2 ] 
LátogatKonkrétElemA(KonkrétElemA) LátogatKonkrétElemA(KonkrétElemA) 
LátogatKonkrétElemB(KonkrétElemB) LátogatKonkrétElemB(KonkrétElemB) 





-] ObjektumSzerkezet Elem 

















Fogadílátogató) 
]  KonkrótélemA  — KonkrétélemB  ] 
Fogadílátogatóv] 9 Fogadílátogató v) 1 
MűvelotAl) ; MűveletB[) ! 


! v-sLátogatkonkrétElemAíthis) úg v-oLátogatkonkrétElemBíthis) lá. 











Résztvevők 


Látogató (CsomópontlLátogató) 

— Az objektumszerkezet minden KonkrétElem (ConcreteElement) osztálya számára 
bevezet egy-egy Látogat (Visit) műveletet. A művelet neve és aláírása azonosítja 
a Látogat kérelmet küldő osztályt, így a látogató megállapíthatja a meglátogatott 
elem konkrét osztályát. Ezután a látogató az elemet közvetlenül a megfelelő felü- 
leten keresztül érheti el. 

KonkrétLátogató (TípusEllenőrzőLátogató) 

— Megvalósítja a Látogató (Visitor) által bevezetett műveleteket. Minden művelet az 
algoritmusnak a megfelelő osztályú objektum számára meghatározott részét való- 
sítja meg. A KonkrétLátogató (ConcreteVisitor) biztosítja az algoritmus környeze- 
tét, és tárolja annak helyi állapotát. Gyakran ez az állapot gyűjti a bejárás során 
összegyűjtött eredményeket. 
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s Elem (Csomópont) 
— Meghatároz egy Fogad (Accept) műveletet, amelynek argumentuma egy látogató. 
e  KonkrétElem (ÉrtékadásCsomópont, VáltozóHivCsomópont) 
— Megvalósít egy Fogad műveletet, amelynek argumentuma egy látogató. 
e  ObjektumSzerkezet (Program) 
— Fel tudja sorolni az elemeit. 
— Magasszintű felületet biztosíthat, amelynek révén a látogató meglátogathatja az 
objektumszerkezet elemeit. 
— Lehet összetétel (lásd az Összetétel tervezési mintát a 4. fejezetben) vagy gyűjte- 
mény, például lista vagy halmaz. 


Együttműködés 


e A Látogató mintát alkalmazó ügyfélnek létre kell hoznia egy KonkrétLátogató objek- 
tumot, majd a látogatóval minden elemet végiglátogatva be kell járnia az objektum- 
szerkezetet. 

e Amikor egy elemhez látogató érkezik, az elem meghívja az osztályának megfelelő 
Látogató műveletet, és átadja magát argumentumként, hogy a látogató megismerhes- 
se állapotát, ha szükséges. 

Az alábbi együttműködési diagram egy objektumszerkezet, egy látogató, valamint 
két elem együttműködését mutatja: 























egyObjektumSzerkezet egyKonkrétElemA egyKonkrétElemB egyKonkrétLátogató 
n. Fogad(egyLátogató) ] 
T] LátogatkKonkrétElemA fegyKKonkrétElemA) vs 
MűveletA() 
Fogad(egyLátogató) 
LátogatKonkrétElemB(egyKonkrétElemB) 94 A 
MűveletBi) 
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Következmények 


A Látogató minta előnyei és hátrányai többek között a következők: 


1. 


4. 


Megkönnyíti új műveletek hozzáadását. A látogatók megkönnyítik az olyan művele- 
tek hozzáadását, amelyek összetett objektumok elemeitől függnek. Az objektum- 
szerkezet új művelettel való bővítéséhez így elég, ha új látogatót készítünk. 
Ha a szolgáltatásokat több osztályban szórnánk szét, új művelet felvételéhez az 
összes osztályt meg kellene változtatnunk. 
A látogató összegyűjti a rokon műveleteket, és elválasztja a kapcsolatban nem álló- 
kat. A rokon szolgáltatások nem az objektumszerkezetet meghatározó osztályokban 
oszlanak el; egy látogató gyűjti össze azokat. A kapcsolatban nem álló műveletek sa- 
ját látogató alosztályaikban kapnak helyet. Ez a rendszer egyszerűsíti mind az eleme- 
ket leíró osztályokat, mind a látogatókban meghatározott algoritmusokat. A látoga- 
tókban bármilyen algoritmusfüggő adatszerkezet elrejthető, 
Új KonkrétElem osztályt nehéz hozzáadni. A Látogató minta megnehezíti az Elemből új 
alosztályok származtatását. Minden új KonkrétElem új elvont műveletet von maga után 
a Látogatóban, illetve ezek megvalósítását a KonkrétLátogató osztályokban. Egyes ese- 
tekben a Látogató osztály alapértelmezett megvalósítást nyújthat, amelyet a Konkrét- 
Látogatók többsége örökölhet, de ez inkább kivételnek, mintsem szabálynak számít. 
A fentiek miatt a Látogató minta alkalmazásának kulcsfontosságú kérdése, hogy az 
objektumszerkezetben használt algoritmus módosítása valószínűbb-e, vagy a szer- 
kezetet felépítő objektumosztályoké. Amennyiben gyakran veszünk fel új Konkrét- 
Elem osztályokat, a Látogató osztályhierarchia fenntartása nehézzé válhat. Ilyen eset- 
ben valószínűleg egyszerűbb, ha csak a szerkezetet alkotó osztályokban határozzuk 
meg a műveleteket. Ha viszont az Elem osztályhierarchia stabil, de a programot 
rendszeresen bővítjük új műveletekkel, vagy gyakran módosítjuk az algoritmusokat, 
a Látogató minta jó szolgálatot tehet a változások kezelésében. 
A látogatás átívelhet az osztályhierarchiákon. A bejárók (lásd a Bejáró mintát a fejezet 
korábbi részében) is meglátogathatják egy szerkezet objektumait, miközben bejárják 
azokat műveleteik meghívásával, de különböző típusú elemekből álló objektumszer- 
kezeteken nem ívelhetnek keresztül. A fejezetben korábban bemutatott Iterator (Bejá- 
ró) felület például csak az Item (Elem) típusú objektumokat képes elérni: 

templatexzclass Items 

elass Iterator ( 


kbsei 
Item Currentltem() const; 








hi; 


Ez a kód azt jelenti, hogy a bejáró kizárólag olyan elemeket látogathat meg, amelyek 
szülője az Item osztály. A Látogató mintában ilyen korlátozás nincs. Bármilyen szü- 
lővel rendelkező objektumok meglátogathatók, és a Látogató felületekhez bármilyen 
típusú objektum hozzáadható. 
class Visitor ( 
Pübliés 
Zaftszere 
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void VisitMyType((MyTyper" ) ; 
void VisitYourType(YourTypes ) ; 
hi; 
A fenti kódban például a MyType (EnyémTípus) és a YourType (TiédTípus) egyál- 
talán nem kell, hogy öröklés révén rokonságban álljanak. 

5. Az állapot tárolható. A látogatók összegyűjthetik az állapotinformációkat, ahogy az 
objektumszerkezetben végiglátogatják az elemeket. Látogató nélkül az állapotot 
a bejárást végző műveletnek kiegészítő argumentumként adnánk át, esetleg erre 
a célra globális változókat használnánk. 

6. Megsértheti az egységbe zárást. A Látogató minta által alkalmazott megközelítés fel- 
tételezi, hogy a KonkrétElem felület elég , erős" ahhoz, hogy a látogatók munkáját tá- 
mogassa. Ebből következik, hogy a minta gyakran arra kényszerít, hogy olyan nyil- 
vános műveleteket adjunk meg, amelyek hozzáférnek egy elem belső állapotához, 
ami megsértheti az egységbe zárás elvét. 


Megvalósítás 


Minden objektumszerkezethez tartozik egy kapcsolódó Látogató osztály. Ez az elvont osztály 
a szerkezetet felépítő valamennyi KonkrétElem osztály számára bevezet egy-egy Látogat- 
KonkrétElem (VisitConcreteElement) műveletet. A Látogató minden Látogat (Visi0 művelete 
argumentumként egy adott KonkrétElemet ad meg, így a látogató a konkrét elemek felületét 
közvetlenül elérheti. A KonkrétLátogató osztályok a Látogat műveletek felülbírálásával való- 
sítják meg a nekik megfelelő KonkrétElem osztályok látogatófüggő viselkedését. 


A Látogató (Visitor) osztályt a C4t-ban a következőképpen vezethetjük be: 


class Visitor ( 

public: 
virtual void VisitElementA (ElementAt ) ; 
virtual void VisitElementB( ElementbBt ) ; 


// és így tövább a többi konkrét elem esetében is 
protected: 

Visitor(); 
ha 


Minden KonkrétElem osztály megvalósít egy Accept (Fogad) műveletet, amely az osztály- 
hoz tartozó látogató megfelelő Visit . . . (Látogat...) műveletét hívja meg. Így az, hogy 
melyik lesz a meghívott művelet, mind az elem, mind a látogató osztályától függ." 





19 Ha függvénytúlterhelést alkalmaznánk, a műveleteknek ugyanazt az egyszerű nevet (pl. visit) adhatnánk, mi- 
vel az átadott paraméter kellőképpen megkülönbözteti őket. E megoldás mellett és ellen egyaránt szólnak érvek. 
A túlterhelés egyrészt megerősíti, hogy a műveletek valójában ugyanazt az elemzést végzik, csak más-más argu- 
mentummal, másrészt viszont homályosabbá teheti a kódot olvasó számára, hogy mi is történik a hívás helyén. 
A döntést csak az befolyásolja, hogy általában jó megoldásnak tartjuk-e a függvénytúlterhelést, vagy sem, 
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A konkrét elemeket az alábbi módon vezetjük be: 


class Element ( 


public: 

virtual "7Element ( ) ; 

virtual void Accept(Visitorg) - 0; 
protected: 

Element ( ) ; 


ís 


class ElementA : public Element ( 
public: 
ElementA ( ) ; 
virtual void Accept(Visitorg v) ( v.VisitElementA(this); ) 


1; 


class ElementB : public Element ( 
public: 
ElementB( ) ; 
virtual void Accept(Visitorg v) ( v.VisitElementBíthis); ) 


1; 


Egy CompositeElement (ÖsszetettElem) osztály az Accept műveletet a következőkép- 
pen valósítaná meg: 


class CompositeElement : public Element ( 
buöliöt 

virtual void Accept (Visitorf£); 
private: 

ListcElementtst — children; 
hi; 


void CompositeElement::Accept (Visitorg v) ( 
ListlteratorcElementts i( children) ; 


for (i.First(); !i.IsDóne(); i.Next()) ( 
i.CurrentItem( ) sAccept (v) ; 
j 
v.VisitCompositeElement (this) ; 


) 
A Látogató minta alkalmazásakor két további megvalósítási kérdéssel kell foglalkoznunk: 
1. Kettős közvetítés. A Látogató minta végeredményben azt teszi lehetővé, hogy az osztá- 


lyokhoz azok megváltoztatása nélkül adhassunk új műveleteket. A minta ehhez az úgy- 
nevezett kettős közvetítés (double-dispatch) megoldást használja. Ez jól ismert eljárás, né- 
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hány programozási nyelv (például a CLOS) közvetlenül támogatja. A C---t, a Smalltalk és 
más hasonló nyelvek az egyszeres közvetítést (single-dispatch) alkalmazzák. 

Az egyszeres közvetítésű nyelvekben két tényező határozza meg, melyik művelet tel- 
jesít egy adott kérést: a kérelem neve és a fogadó típusa. Az például, hogy egy 
Előállítkód (GenerateCode) kérelem melyik műveletet hívja meg, attól függ, milyen tí- 
pusú a címzett csomópont objektum. A C-t--ban a GenerateCode meghívása egy 
VariableRefNode (VáltozóHivCsomópon?t) példányra a VariableRefNode : : Ge- 
nerateCode hívást eredményezi (ami egy változóhivatkozás számára állít elő kódot), 
ha pedig egy AssignmentNode-ra (ÉrtékadásCsomópon?) hívjuk meg, az eredmény 
az AssignmentNode : : GenerateCode lesz (ezzel egy értékadás kódját állítjuk elő). 
A végrehajtott művelet a kérelem fajtájától és a fogadó típusától is függ. 

A kettős közvetítés mindössze annyit jelent, hogy a végrehajtott művelet a kérelem 
fajtája mellett két fogadó típusától függ. Az Accept kettős közvetítésű művelet, jelen- 
tése két típustól, a látogatóétól és az elemétől függően változik. A kettős közvetítés 
révén a látogatók különböző műveleteket kérhetnek minden elemosztályra." 

Ez a Látogató minta kulcsa: a végrehajtott művelet mind a látogató, mind a megláto- 
gatott elem típusától függ. A műveleteket nem szerkesztjük be statikusan az Elem fe- 
lületbe, hanem a Látogatóba helyezzük azokat, és az Accept használatával futásidő- 
ben hozzuk létre a kötést. Így az Elem felület bővítése csupán egyetlen új Látogató 
alosztály létrehozásával jár, nem pedig számos Elem alosztály meghatározásával. 

2. Ki felel az objektumszerkezet bejárásáért? A látogatónak végig kell járnia az objek- 
tumszerkezet valamennyi elemét. A kérdés csak az, hogyan éri ezt el? A bejárás fel- 
adatát három helyen helyezhetjük el: az objektumszerkezetben, a látogatóban, illet- 
ve egy önálló bejáró objektumban (lásd a Bejáró tervezési mintát). 

Gyakran az objektumszerkezet felel a bejárásért. Egy gyűjtemény például egyszerű- 
en a Fogad művelet többszöri meghívásával járja végig az elemeit. Az összetételek 
bejárása során a Fogad ismétlődő önhívással megy végig az elem gyermekein. 

Egy másik megoldás, ha az elemek meglátogatására egy bejárót használunk. A C---- 
nyelvben belső és külső bejárót is használhatunk, attól függően, hogy melyik elérhe- 
tő, illetve melyik a hatékonyabb. A Smalltalkban általában belső bejárókat alkalmaz- 
nak, a do : és egy programblokk segítségével. Miután a belső bejárókat az objektum- 
szerkezet valósítja meg, a belső bejárók használata nem sokban különbözik attól, 
mintha az objektumszerkezetet tennénk felelőssé a bejárásért. A fő különbség az, 
hogy a belső bejárók nem járnak kettős közvetítéssel: a műveletet a látogatóra hívják 
meg, és a művelet argumentuma egy adott elem lesz, nem pedig egy elemre, a láto- 
gatóval mint argumentummal. Mindazonáltal a Látogató minta könnyen használható 
belső bejáróval is, ha a látogató művelete egyszerű, önhívás nélküli művelethívást 
intéz az elemhez. 





" Ha létezik kettős közvetítés, lehetséges hármas, négyes vagy még többes" is? Nos, a kettős közvetítés való- 
jában csak a többszörös közvetítés (multiple dispatch) egyik esete, amelyben a műveletet típusok valami- 
lyen száma alapján választjuk ki. (A CLOS ténylegesen a többszörös közvetítést támogatja.) A kettős vagy 
többszörös közvetítést támogató nyelvekben kevésbé szükséges a Látogató minta alkalmazása. 
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A bejáró algoritmus a látogatóba is helyezhető, bár így a bejárás kódját minden 
összesített (aggregá0) KonkrétElem minden KonkrétLátogató osztályában újra és újra 
megkettőzzük. A bejárási stratégiának a látogatóba helyezésére abban az esetben le- 
het jó okunk, ha különösen bonyolult bejárást valósítunk meg, amely az objektum- 
szerkezeten végzett műveletek eredményétől függ. A Példakód részben látunk majd 
egy ilyen esetet. 


Példakód 


Mivel a látogatók általában az összetételekhez kapcsolódnak, a Látogató minta illusztrálásá- 
nál az Összetétel minta Példakód részében bemutatott Eguipment (Eszközök) osztályokra 
fogunk támaszkodni. A Látogató mintát arra használjuk majd, hogy műveleteket határoz- 
zunk meg egy eszközleltár összeállításához, illetve az egyes eszközök teljes költségének ki- 
számításához. Az Eguipment osztályok annyira egyszerűek, hogy a Látogató minta alkal- 
mazása tulajdonképpen szükségtelen, de a példán könnyen bemutatható, mire van szük- 
ség a minta megvalósításához. 


Álljon itt ismét az Összetétel mintánál (4. fejezeÜ) megismert Eguipment osztály, amelyet 
kibővítettünk egy Accept művelettel, hogy képes legyen együttműködni a látogatókkal: 


class Eguipment ( 
public: 


virtual "Eguipment ( ) ; 
const char" Name() ( return name; ) 


virtual Watt Power -(); 
virtual Currency NetPrice(); 
virtual Currency DiscountPrice() ; 


virtual void Accept (EguipmentVisitor€) ; 
protected: 

Edguipment (const char"); 
private: 

const char: name; 


); 


Az Eguipment műveletei egy adott eszköz tulajdonságait adják vissza, például a fogyasztá- 
sát és a költségét. Az alosztályok a különböző eszköztípusoknak (ház, meghajtók, kártyák 
stb.) megfelelően felülírják a műveleteket. 





Az eszközök látogatóinak elvont osztálya minden eszköz-alosztály számára tartalmaz egy 
elvont függvényt, amint azt az alábbi kódban láthatjuk. Alapértelmezés szerint a virtuális 
függvények egyike sem csinál semmit. 
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class EguipmentVisitor ( 
publier 


virtual "EguipmentVisitor(); 


virtual void VisitFloppyDisk(FloppyDisk? ) ; 
virtual void VisitCard(Cardt ) ; 

virtual void VisitChassis(ChassisfY); 
virtual void VisitBus(Bus?) ; 


// és így tovább az Eguipment minden konkrét alosztályára 
protected: 


EguipmentVisitor() ; 
: 6 


Az Eguipment alosztályai az Accept műveletet lényegében ugyanúgy határozzák meg: 
a művelet meghívja azt az EguipmentVisitor műveletet, amelyik megfelel az Accept 
kérelmet kapó osztálynak: 


void FloppyDisk::Accept (EguipmentVisitorg visitor) ( 
visitor.VisitFloppyDiskí(this) ; 
1 


Azok az eszközök, amelyek más eszközöket foglalnak magukba (az Összetétel mintánál 
ezek a CompositeEguipment alosztályai), úgy valósítják meg az Accept műveletet, hogy 
bejárják gyermekeiket és mindegyikre meghívják. Ezután a szokásos módon meghívják 
a Visit műveletet. A Chassis : : Accept például a házban található eszközöket a követ- 
kezőképpen járja be: 


void Chassis::Accept (EguipmentVisitorg visitor) ( 
tor ( 
ListIlteratorcEguipmentts i( parts); 
!i.Is.Done() ; 
i.Next() 


i.CurrentItem( ) sAccept (visitor) ; 


visitor.VisitChassisíthis) ; 


Az EguipmentVisitor alosztályai a szerkezet egyes részeire vonatkozó egyedi algorit- 
musokat határozzák meg. A Pricingvisitor (ÁrazóLátogató) az összes eszköz költségét 
számítja ki. Kiszámolja az egyszerű eszközök (pl. hajlékonylemezek) nettó árát, illetve az 
összetett eszközök (pl. ház) leszállított árát. 


class PricingVisitor : public EguipmentVisitor ( 
public: 
PricingVisitor(); 
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Currencyg GetTotalPrice(); 


virtual void VisitFloppyDisk(FloppyDisk") ; 
virtual void VisitCard(Cardt) ; 
virtual void VisitChassis(Chassis?) ; 
virtual void VisitBus(Bus?) ; 
Elv és 

private: 
Currency total; 

); 


void PricingVisitor::VisitFloppyDisk (FloppyDisk" e) ( 
.-total 4- e-sNetPrice(); 


) 


void PricingVisitor::VisitChassis (Chassis"t e) ( 
.-total 4- e-sDiscountPrice(); 


) 


A PricingVisitor a szerkezet minden csomópontjának teljes költségét kiszámítja. Meg- 
figyelhetjük, hogy az egyes eszközosztályok árazási módját úgy választja ki, hogy a megfe- 
lelő tagfüggvényhez fordul. Az árazási módszer így meg is változtatható, ehhez elég 
a PricingVisitor osztályt módosítani. 


A leltárkészítő látogatót valahogy így határozhatjuk meg: 


class InventoryVisitor : public EguipmentVisitor ( 
public: 
InventoryVisitor ( ) ; 


Inventoryg Getlnventory ( ) ; 


virtual void VisitFloppyDisk(FloppyDiskt ) ; 
virtual void VisitCard(Card?) ; 

virtual void VisitChassis(Chassist) ; 
virtual void VisitBus(Bus") ; 

VÉ és 


private: 
Inventory . inventory ; 
1; 


Az InventoryVisitor (LeltárLátogató) összegyűjti az egyes eszköztípusokra vonatkozó 
összegeket, emellett pedig az Inventory (Leltár) osztály segítségével felületet határoz 
meg az eszközök hozzáadására (ezt itt nem részletezzük). 
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void InventoryVisitor::VisitFloppyDisk (FloppyDisk" e) ( 
.inventory.Accumulate (e) ; 


3 


void InventoryVisitor::VisitChassis (Chassist e) ( 
.inventory.Accumulate (e) ; 


) 
Az InventoryVisitor-t a következőképpen használhatjuk a teljes elemkészletre: 


Eguipmentt component; 
InventoryVisitor visitor; 


component-sAccept (visitor) ; 
cout cc "Inventory " 

aZ component-5Name ( ) 

cz visitor.GetInventory ( ) ; 


Most pedig megnézzük, hogyan valósítható meg az Értelmező mintánál bemutatott 
Smalltalk példa a Látogató minta használatával. Az előzőhöz hasonlóan ez a példa is olyan 
egyszerű, hogy a Látogató mintával valószínűleg nem nyerünk sokat, de illusztrációnak tö- 
kéletes, mert a minta használata mellett egy olyan helyzetet is bemutat, ahol a bejárás a lá- 
togató felelőssége. 


Az objektumszerkezet (szabályos kifejezések) négy osztályból áll, melyek mindegyike ren- 
delkezik egy accept: metódussal, amelynek argumentuma a látogató. A Seguence- 
Expression (Sorozatkifejezés) osztályban ennek alakja a következő: 


accept: aVisitor 
" aVisitor visitSeguence: self 


Az accept: a RepeatExpression (IsmétléskKifejezés) osztályban a visitRepeat : , az 
AlternationExpression (VálasztásKifejezés) osztályban a visitAlternation:, 
a LiteralExpression (literálkKifejezés) osztályban a visitLiteral : üzenetet küldi. 


A négy osztálynak elérő függvényekkel is kell rendelkeznie, amelyeket a látogató használ- 
hat. A SeguenceExpression esetében ezek az expressionl és expression2, az 
AlternationExpression esetében az alternativel és alternative2, a Repeat- 
Expression esetében a repetition, a LiteralExpression-nél pedig a components. 


A KonkrétLátogató osztály a REMatchingVisitor (IsmillesztőLátogató). Ez az osztály fe- 
lel a bejárásért, mert a bejáró algoritmus nem szabályos, ami leginkább abban nyilvánul 
meg, hogy a RepeatExpression újra és újra bejárja az összetevőjét. A REMatching- 
Visitor osztály egy inputState nevű példányváltozóval rendelkezik, metódusai pedig 
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lényegében megegyeznek az Értelmező minta kifejezésosztályainak match: (illeszÖ metó- 
dusaival, csak ezekben az inputState argumentum helyén az illesztendő kifejezés-cso- 
mópont áll. Mindazonáltal, amit visszaadnak, az továbbra is azon adatfolyamok halmaza, 
amelyekre a kifejezés az aktuális állapot azonosításához illeszkedik. 


visitSeguence: seguenceExp 
inputState :- seguenceExp expressionl accept: self. 
" seguenceExp expression2 accept: self. 


visitRepeat: repeatExp 

Il finalState I 

finalState :- inputState copy. 

(inputState isEmpty] 

whileFalse: 

([inputState :- repeatExp repetition accept: self. 
finalState addAll: inputStatej. 

" finalState 


visitAlternation: alternateExp 
Il finalState originalState I 


originalState :- inputState. 
finalState :- alternateExp alternativel accept: self. 
inputState :- originalState. 


finalState addAll: (alternateExp alternative2 accept: self). 
" finalState 


visitLiteral: literalExp 
Il finalState tStream I 





finalState :- Set new. 
inputState 
do: 
(:stream I tStream :- stream copy. 


(tStream nextAvailable: 
literalExp components size 
) - literalExp components 
ifTrue: [finalState add: tStream] 


" finalState 


Ismert felhasználások 


A Smalltalk-80 fordítóprogram tartalmaz egy látogató osztályt, a ProgyramNodeEnumerator 
(ProgramCsomópontFelsoroló) nevűt, amelyet elsősorban a forráskódot elemző algoritmu- 
sok használnak. Kód-előállításra vagy kimenetformázásra nem használatos, pedig alkalmas 
volna rá. 
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Az IRIS Inventor IStr93] térbeli grafikus alkalmazások fejlesztésére szolgáló elemkészlet. 
A háromdimenziós helyszíneket (scene) csomópontok hierarchiájaként ábrázolja, amelyek 
mindegyike egy-egy mértani alakzatot jelöl, vagy annak egy tulajdonságát. Az olyan műve- 
letek, mint a helyszínek leképezése vagy a bemeneti események hozzárendelése ezen hie- 
rarchia különböző módokon való bejárását igényli, amit az Inventor műveleteknek (action) 
nevezett látogatókon keresztül old meg. Külön látogatók vannak a leképezésre, az ese- 
ménykezelésre, a keresésre, illetve a befoglaló dobozok meghatározására. 


Az új csomópontok felvételét megkönnyítendő az Inventor kettős közvetítési sémát valósít 
meg Ct--ban. A séma a futásidejű típusinformációkra épül, illetve egy kétdimenziós táblá- 
zatra, amelynek sorai a látogatókat, oszlopai pedig a csomópont osztályokat jelképezik. 
A cellák a látogatóhoz, illetve a csomópont osztályhoz kapcsolódó függvényt címző muta- 
tót tartalmazzák. 


A Látogató (Visitor) elnevezést Mark Linton használta először, az X Consortium Fresco 
Application Toolkit leírásában [LP93]. 


Kapcsolódó minták 


Összetétel: A látogatók segítségével egy, az Összetétel mintával meghatározott objektum- 
szerkezet elemein végezhetünk el egy adott műveletet. 


Értelmező: Az értelmezést látogatóval is végezhetjük. 
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A viselkedési mintákról 
A változatok egységbe zárása 


A változó elemek egységbe zárása számos viselkedési minta alapja. Amikor egy program 
valamelyik tényezője gyakran változik, ezen minták segítenek abban, hogy egy objektum- 
ban egységbe zárhassuk. A program többi része ezután együttműködhet ezzel az objek- 
tummal, ha működésük az említett tényezőtől függ. A viselkedési minták általában egy el- 
vont osztályt határoznak meg, amely leírja az egységbe záró objektumot, és nevüket erről 
az objektumról kapják:? 


s a Stratégia objektum egy algoritmust zár egységbe (Stratégia minta), 

s az Állapot objektum egy állapotfüggő viselkedést (Állapot minta), 

s a Közvetítő objektum objektumok közötti protokollt (Közvetítő minta), 

s a Bejáró objektum pedig az összesített objektumok (aggregátumok) elemeinek el- 
érésére és bejárására szolgáló módszert. 


Az említett minták a program egy olyan részét írják le, amelyet működés közben valószínű- 
leg cserélgetünk. A legtöbb minta kétféle objektumot tartalmaz: új objektumokat, amelyek 
egységbe zárják a kérdéses szolgáltatást, illetve már meglevőket, amelyek ezen új objektu- 
mokat használják. Az új objektumok nyújtotta szolgáltatások az adott minta használata nél- 
kül általában a már létező objektumok szerves részei lennének. Egy stratégia kódját példá- 
ul a stratégia környezetébe (Környezet, Contex0) ,drótoznánk", egy állapotobjektum kódját 
pedig közvetlenül az állapot környezetében valósítanánk meg. 





Mindazonáltal nem minden objektumviselkedési minta a fenti felosztást alkalmazza. A Fele- 
lősséglánc mintában például tetszőleges számú (a láncot alkotó) objektummal dolgozha- 
tunk, amelyek mindegyike lehet a rendszerben már létező objektum. 


A Felelősséglánc minta még egy különbségre rávilágít a viselkedési minták között: nem 
mindegyik statikus kapcsolatokat határoz meg az osztályok között. A Felelősséglánc minta 
objektumok korlátlan száma közötti kommunikációt ír elő, míg más mintákban olyan ob- 
jektumokat találunk, amelyeket argumentumként adunk át. 


Argumentumként használt objektumok 


Számos tervezési minta vezet be egy olyan objektumot, amelyet mindig argumentum- 
ként használunk. Az egyik ilyen minta a Látogató. A látogató objektum egy többalakú 
Fogad (Accept) művelet argumentuma, amely a meglátogatott objektumokon működik. 





2 Más minták is hasonlóan működnek. Az Elvont gyár, az Építő és a Prototípus minták mind objektumok létrehozásá- 
nak módját zárják egységt 





a Díszítő minta olyan szolgáltatásokat, amelyekkel egy objektum kiegészíthető; a Híd 
minta az elvont ábrázolást választja el a megvalósítástól, hogy azok egymástól függetlenül változtathatók legyenek. 
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A látogatót soha nem kezeljük ezen objektumok részeként, pedig a minta alkalmazásá- 
nak hagyományos alternatívája a látogató kódjának elosztása az objektumszerkezet osz- 
tályai között. 


Más minták olyan objektumokat határoznak meg, amelyek mágikus jelként viselkednek, ami- 
ket körbeadunk és később meghívunk. Mind a Parancs, mind az Emlékeztető minta ebbe 
a kategórába esik. A Parancs mintában a mágikus jel (magic token) egy kérelmet jelöl, az Em- 
lékeztetőben egy objektum belső állapotát egy adott pillanatban. A jel mindkét esetben bonyo- 
lult belső szerkezetű lehet, de erről az ügyfélnek nincs tudomása. Mindazonáltal itt is találunk 
különbségeket. A Parancs mintában lényeges szerepet játszik a többalakúság (polimorfizmus), 
hiszen a Parancs (Command) objektum végrehajtása többalakú művelet. Ezzel szemben az 
Emlékeztető (Memento) felület olyan , keskeny", hogy az emlékeztető csupán értékként adha- 
tó át, így nem valószínű, hogy egyetlen többalakú műveletet is nyújtana az ügyfeleinek. 


Egységbe zárás vagy elosztás? 


A Közvetítő és a Megfigyelő egymással versengő tervezési minták. A különbség köztük az, 
hogy a Megfigyelő a Megfigyelő (Observer) és Alany (Subject) objektumok bevezetésével 
elosztja a kommunikációt, míg a Közvetítő (Mediator) objektumok éppen hogy egységbe 
zárják a többi objektum közötti kapcsolattartást. 


A Megfigyelő mintában nem egyetlen objektum zár egységbe egy kötést; a Megfigyelőknek 
és Alanyoknak együtt kell működniük annak fenntartása érdekében. A kapcsolattartási min- 
tákat a megfigyelők és alanyok összekapcsolásának módja határozza meg: az egyedülálló ala- 
nyoknak általában több megfigyelőjük van, de egy megfigyelő is lehet egy másik megfigyelő 
alanya. A Közvetítő minta nem eloszt, inkább központosít; a kötések fenntartásának felelős- 
ségét kifejezetten a közvetítőkre bízza. A szerzők könnyebben újrahasznosíthatónak találták 
a Megfigyelő és Alany objektumokat, mint a közvetítőket. A Megfigyelő minta a megfigyelők 
és alanyok közötti elosztást és laza csatolást részesíti előnyben, ami , finomabb" osztályszer- 
kezetet eredményez, a kisebb osztályokat pedig könnyebb újrahasznosítani. 








A Közvetítő mintában viszont átláthatóbb a kommunikáció folyása, mint a Megfigyelőben. 
A megfigyelők és alanyok általában röviddel létrehozásuk után összekapcsolódnak, így 
a programban később nehéz felderíteni kapcsolódásuk módját. Ha ismerjük a Megfigyelő 
mintát, tisztában vagyunk vele, hogy a kapcsolódás módjának ismerete lényeges, és azt is 
tudjuk, milyen kapcsolatokat keressünk, a minta által bevezetett közvetettség azonban en- 
nek ellenére megnehezítheti egy rendszer megértését. 


A megfigyelők a Smalltalkban üzenetparamétereket kaphatnak az alany állapotának eléré- 
séhez, így újrahasznosításuk még egyszerűbb, mint a C--ban. A Smalltalkban ezért von- 
zóbb a Megfigyelő minta, mint a Közvetítő, míg a Ctt programozók inkább az utóbbit ré- 
szesítik előnyben. 
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A küldő és a fogadó elválasztása 


Amikor az együttműködő objektumok közvetlenül hivatkoznak egymásra, függővé válnak 
egymástól, ami nemkívánatos hatással van a rendszer rétegezettségére és újrahasznosítható- 


ságára. A Parancs, a Megfigyelő, a Közvetítő és a Felelősséglánc minták mind érintik a kül- 
dők (adók) és fogadók (vevők) elválasztásának kérdését, de más-más következményekkel. 


A Parancs minta az elválasztást egy olyan Parancs (Command) objektummal támogatja, 
amelynek feladata a küldő és a fogadó kötésének meghatározása: 


egyKezdeményező egyParancs egyFogadó 
(küldő) (fogadó) 


Végrehajt() ) 


A Parancs objektum egyszerű felületet biztosít a kérelem kibocsátásához (vagyis a Végrehajt 
művelethez). A küldő-fogadó kapcsolat önálló objektumba helyezése lehetővé teszi a küldő- 
nek, hogy különböző fogadókkal dolgozzon, emellett elválasztja a küldőt a fogadóktól, így 
megkönnyíti annak újrahasznosítását. A Parancs objektum is újrahasznosítható a fogadó kü- 
lönböző küldőkkel való paraméterezéséhez. A Parancs minta elvileg minden küldő-fogadó 
kapcsolathoz külön alosztályt igényel, de a minta leír olyan megvalósítási módszereket, ame- 
lyekkel az alosztályok származtatása elkerülhető. 


A Megfigyelő minta az alanyok megváltozását jelző felület meghatározásával választja szét 
a küldőt (alany) a fogadótól (megfigyelő). A Megfigyelő minta lazább kötést alakít ki közöttük, 
mint a Parancs, mivel egy alanynak több megfigyelője lehet, és számuk futásidőben változhat. 





egyAlany egyMegfigyelő egyMegfigyelő egyMegfigyelő 
(küldő) (fogadó) (fogadó) (fogadó) 
! 
Frissít() 
Frissítt) 





Frissít() 
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A Megfigyelő minta Alany és Megfigyelő felületeinek szerepe a változások közlése, ezért 
a minta akkor alkalmazható legjobban objektumok elválasztására, ha adatfüggőségek áll- 
nak fenn köztük. A Közvetítő minta az objektumokat úgy választja el, hogy megköveteli, 
hogy egy közvetítőn keresztül közvetetten hivatkozzanak egymásra. 


egyKolléga egyKözvetítő egyKolléga egyKolléga 
(küldő/fogadó) (küldő/fogadó) (küldő/fogadó) 
I 




















hal tj 

















Ld 


A Közvetítő objektumok a kérelmeket Kolléga (Colleague) objektumokhoz továbbítják, és 
központosítják a közöttük folyó kommunikációt. Ennek következményeképpen a kollégák 
csak a közvetítő felületén keresztül társaloghatnak egymással. Mivel ez a felület rögzített, 
a nagyobb rugalmasság érdekében a közvetítőnek esetleg saját üzenetküldő sémát kell 
megvalósítania. A kérelmek kódolása és az argumentumok becsomagolása így oly módon 
történhet, hogy a kollégák korlátlan számú műveletet kérelmezhetnek. 





A Közvetítő minta csökkenti az alosztályok létrehozásának szükségességét a rendszerben, 
mivel a kapcsolattartási viselkedést egyetlen osztályban egyesíti, nem pedig alosztályok 
között osztja szét. Mindazonáltal az ad hoc üzenetküldő sémák gyakran csökkentik a típus- 
biztonságot. 


A Felelősséglánc minta a küldőt és a fogadót úgy választja el, hogy a kérelmeket a lehetsé- 
ges fogadók láncán küldi át: 





egyÜgyfél egyKezelő egyKezelő egyKezelő 
(küldő) (fogadó) (fogadó) (fogadó) 
! 
KezelSúgót) 
KezelSúgó() 


KezelSúgót) 
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Miután a küldők és fogadók közötti felület rögzített, a Felelősséglánc minta szintén egyedi 
üzenetküldő sémát igényelhet, ami ugyanazokat a típusbiztonsággal kapcsolatos gondokat 
veti fel, mint a Közvetítő mintánál. A Felelősséglánc minta a küldő és a fogadó szétválasztá- 
sára akkor jó megoldás, ha a lánc már a rendszer szerkezetének része, és valamelyik objek- 
tum képes kezelni a kérelmet. A minta emellett rugalmas, mert a lánc módosítható és 
könnyen bővíthető. 


Összegzés 


Néhány kivételtől eltekintve a viselkedési minták kiegészítik és erősítik egymást. Egy fele- 
lősséglánc egyik osztálya például valószínűleg legalább egy helyen alkalmaz Sablonfügg- 
vényt; a sablonfüggvény alapműveletek segítségével megállapíthatja, hogy az objektum ké- 
pes-e a kérelem kezelésére, illetve kiválaszthatja azt az objektumot, amelynek a kérelmet 
továbbítani kell. Ezenkívül a lánc a Parancs minta alkalmazásával a kérelmeket objektu- 
mokként ábrázolhatja. Az Értelmező minta az elemző környezetet az Állapot minta segítsé- 
gével alakíthatja ki. Egy bejáró bejárhat egy összetételt, annak elemeire pedig egy látogató 
alkalmazhat műveleteket. 





A viselkedési minták jól működnek együtt más mintákkal. Egy, az Összetétel mintát hasz- 
náló rendszer például egy látogató segítségével hajthat végre műveleteket az összetétel ele- 
mein, a Felelősséglánc minta révén lehetővé teheti az elemeknek, hogy szülőjükön keresz- 
tül globális tulajdonságokat érjenek el, sőt, a Díszítő mintával az összetétel egyes elemei- 
ben felül is bírálhatja ezen tulajdonságokat. Emellett a Megfigyelőt mintát alkalmazva egy 
objekumszerkezetet egy másikhoz köthet, az Állapot mintával pedig megváltoztathatja egy 
elem viselkedését, amint az állapota megváltozik. Maga az összetétel létrehozható az Építő 
minta megközelítésével, a rendszer valamely más része pedig prototípusként is kezelheti az 
összetételt. 


A jól megtervezett objektumközpontú rendszerek éppen ilyenek — számos minta ágyazódik 
beléjük, de nem feltétlenül azért, mert tervezőik erre törekedtek. Az osztályok vagy objek- 
tumok szintje helyett a minták szintjén történő tervezés számunkra is megkönnyíti, hogy 
hasonló szervezettséget érjünk el. 


Tanulságok 


Egyesek úgy gondolhatják, számukra ez a könyv nem nyújtott túl sokat. Tény, hogy nincse- 
nek benne korábban ismeretlen algoritmusok és különféle programozási eljárások. Nem ad 
szigorú módszert a rendszerek tervezésére, nem dolgoz ki új tervezési elméletet, csupán le- 
írja a létező tervezési mintákat. Így joggal adódhat a következtetés, hogy bármennyire jól 
összeállított oktatóanyag kezdőknek, az objektumközpontú tervezésben jártas programo- 
zók számára nem tartalmaz hasznosítható ismereteket. 


Reméljük, az Olvasó másként gondolja és egyetért velünk abban, hogy a tervezési minták 
rendszerezése lényeges, mert szabványos meghatározást és nevet ad az általunk használt el- 
járásoknak. Ha nem tanulmányozzuk a különféle programokban fellelhető tervezési mintá- 
kat, továbbfejlesztésükre sem leszünk képesek, és nehezebben állunk majd elő újabbakkal. 


Ez a könyv csupán a kezdőlökést adhatja meg. Azokat a leggyakrabban használt tervezési 
mintákat tartalmazza, amelyeket a tapasztalt objektumközpontú fejlesztők a gyakorlatban 
nap mint nap alkalmaznak, tudomást mégis csak szájhagyomány útján vagy a meglevő 
rendszerek tanulmányozásával szereznek róluk. A kötet korai vázlataiban arra buzdítottuk 
az olvasókat, hogy írják le az általuk használt tervezési mintákat: reményeink szerint a vég- 
leges változat még inkább erre sarkall. Reméljük, ez kezdete lesz egy mozgalomnak, amely 
a szoftverfejlesztők gyakorlati tapasztalatait végre írásban rögzíti. 


Eme utolsó fejezetet annak szenteljük, hogy bemutassuk, szerintünk milyen hatást gyako- 
rolnak a tervezési minták a szoftverfejlesztésre, hogyan kapcsolódnak a tervezéssel kapcso- 
latos egyéb részfeladatokhoz, hogyan találhatunk magunk is itt le nem írt mintákat, és ho- 
gyan rendszerezhetjük azokat. 
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6.1 Mit várjunk egy tervezési mintától? 


Íme néhány terület, amit a kötetben bemutatott tervezési minták az objektumközpontú 
programok fejlesztése során érintenek (gyakorlati tapasztalataink alapján). 


Közös tervezési szókincs 

A programozó szakemberek tapasztalatai a hagyományos programnyelvek terén azt mutat- 
ják, hogy pusztán a nyelvtan ismerete nem nyújt elégséges tudást; szükség van a nagyobb 
fogalmi szerveződések, az algoritmusok, adatszerkezetek, nyelvjárások vagy idiómák 
IAS85, Cop92, Cur89, SS86], illetve az egy adott célhoz igazított tervek [SE84] elsajátítására 
is. A tervezők az adott programterv rögzítésére használt jelölési rendszerre kevesebb figyel- 
met fordítanak; inkább arra összpontosítanak, hogy a tervet a korábban megismert algorit- 
musokhoz, adatszerkezetekhez és idiómákhoz igazítsák. 


A számítógép-tudomány igyekszik elnevezni és rendszerezni az algoritmusokat és adat- 
szerkezeteket, de a tervezési minták esetében ez igen ritkán áll fenn. Pedig a rendszerezett 
tervezési minták közös nyelvet biztosíthatnak a különböző megoldások ismertetéséhez, le- 
írásához vagy felfedezéséhez; emellett azáltal, hogy segítségükkel a programozási nyelvek- 
nél és más jelölési rendszereknél magasabb szinten elvonatkoztatva , beszélhetünk"? egy 
adott tervről, a programot kevésbé bonyolultnak tüntetik fel. A tervezési minták tehát egy- 
szerűsítik mind a tervezést, mind a tervről munkatársainkkal folytatott vitákat. 


Ha elsajátítottuk a kötetben szereplő tervezési mintákat, tervezési szókincsünk is egészen 
biztosan meg fog változni, ahogy elkezdünk az ezek által használt fogalmakban gondol- 
kodni. Fel sem fog tűnni, hogy máris olyanokat mondunk, hogy , használjuk itt a Megfigye- 
lőt" vagy ,csináljunk Stratégiát ezekből az osztályokból. 


Dokumentáció és tanulási segédlet 

A könyvben bemutatott tervezési minták megtanulása könnyebbé teszi a létező rendszerek 
megértését, hiszen a legtöbb nagy méretű objektumközpontú program alkalmazza őket. 
Az objektumközpontú programozást tanulók gyakran panaszkodnak, hogy a rendszer, 
amellyel dolgoznak, bonyolult öröklési viszonyokra épül, így nehéz követni a vezérlési fo- 
lyamatot. Gondjuk nagyrészt abból adódik, hogy nem értik a rendszerben jelen levő terve- 
zési mintákat, pedig ezek ismerete feltétlenül segít az objektumközpontú rendszerek mű- 
ködésének megértésében. 


A tervezési minták segítségével jobb programtervezővé is válhatunk, hiszen e minták gyak- 
ran felbukkanó problémákra nyújtanak megoldást. Ha kellően hosszú ideig dolgozunk ob- 
jektumközpontú rendszerekkel, a mintákat valószínűleg magunk is felfedezzük, de e köny- 
vet elolvasva a tanulási idő jócskán lerövidíthető, így az újonc programozók hamarabb 
szakértővé válhatnak. 


Emellett, ha egy rendszert az általa alkalmazott tervezési minták nevével írunk le, felépíté- 
sét megérteni is jóval könnyebb lesz. Ha nem így teszünk, arra kényszerülünk, hogy a szer- 
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kezetet visszafelé , göngyölítve" jussunk el a használt minták kibányászásáig. A közös szó- 
kincs használata révén nem kell részletesen leírnunk a teljes szerkezetet; elég, ha megne- 
vezzük, így mindenki tudni fogja, miről van szó. Ha mégsem, az illetőnek csak utána kell 
néznie egyszer, hogy milyen tervezési mintát is takar az adott név, ami még mindig egysze- 
rűbb, mint a visszafejtés. 


A szerzők saját munkáikban is alkalmazzák e mintákat, és felbecsülhetetlen értékűnek tart- 
ják azokat. Természetesen a felhasználás módja legtöbbször , naiv": a minták segítségével 
nevet keresünk az osztályoknak, a helyes tervezés oktatásában alkalmazzuk őket, vagy 
a felhasznált tervezési mintákat sorba állítva leírunk egy adott programszerkezetet [BJ94]. 
Ennél kifinomultabb alkalmazás is elképzelhető; a tervezési minták alapján például CASE 
eszközök vagy hiperszöveges dokumentumok is készíthetők, de a minták alapszinten is 
nagy segítséget nyújtanak. 


A létező módszerek kiegészítője 
Az objektumközpontú tervezési módszerek célja, hogy jó tervezésre ösztökéljenek, hogy 
megtanítsák a kezdő programozóknak a helyes tervezés mikéntjét, illetve hogy szabványo- 
sítsák a programfejlesztés módját. Egy tervezési módszer jellemzően azt írja le, hogy a prog- 
ramszerkezet különböző elemeinek modellezésére milyen (általában grafikus) jelölésrend- 
szert használunk, illetve azon szabályokat, amelyek arra vonatkoznak, hogy az egyes szim- 
bólumokat mikor és hogyan alkalmazzuk. A tervezési módszerek rendszerint lehetséges 
problémákat vázolnak, megoldást adnak azokra, és leírják, hogyan mérhetjük fel a tervezés 
helyességét, a szakértő programozók tapasztalatainak megragadására azonban eddig alkal- 
matlannak bizonyultak. 








Úgy véljük, a bemutatott tervezési minták azt a láncszemet jelenthetik, ami eddig hiányzott 
az objektumközpontú tervezési módszerekből. Megmutatják, hogyan használhatjuk az 
alapvető programelemeket - az objektumokat, az öröklést vagy a többalakúságot -, illetve 
azt, hogyan paraméterezhetünk egy rendszert algoritmusokkal, viselkedésekkel, állapotok- 
kal vagy azokkal az objektumokkal, amelyeket létre kell hoznia. Nem csupán döntéseink 
eredményét rögzítik, hanem azt írják le, , miért" legyen olyan a programszerkezet, amilyen. 
A döntések meghozatalában az egyes tervezési minták ismertetésében szereplő Alkalmaz- 
hatóság, Következmények és Megvalósítás részek segíthetnek minket. 


A tervezési minták különösen hasznosak, ha egy elemző modellből szeretnénk megvalósí- 
tási modellt létrehozni. Bár egyesek azt állítják, hogy az objektumközpontú elemzésből 
zökkenőmentes az átmenet az objektumközpontú tervezésbe, a gyakorlatban ez az átme- 
net minden, csak nem sima. Egy rugalmas és újrahasznosítható programszerkezet olyan ob- 
jektumokat is tartalmaz, amelyek az elemző modellben nem szerepelnek, a tervet pedig 
a használt programozási nyelv és osztálykönyvtár is befolyásolja. Az elemző modelleket 
gyakran át kell dolgozni, hogy újrahasznosíthatóvá váljanak. Számos, a gyűjteményünkben 
szereplő minta foglalkozik e kérdéskörrel, ezért is hívjuk őket tervezési mintáknak. 
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Egy teljes tervezési módszer nem csupán tervezési, hanem más típusú mintákat is igényel, 
például elemzési, felhasználóifelület-tervezési vagy teljesítnényfokozási mintákat. A terve- 
zési minták azonban olyan lényeges területet jelentenek, amelyről eddig nem sok szó esett. 


Az újraépítés célja 

Az újrahasznosítható programok fejlesztésének egyik akadálya, hogy gyakran újjászervezé- 
sükre vagy újraépítésükre van szükség. (Ezt hívják idegen szóval refaktorizációnak [OJ90].) 
A tervezési minták segítenek abban, hogy megállapítsuk, milyen újjászervezés szükségelte- 
tik, és a későbbi újraépítés igényét is csökkentik. 


Az objektumközpontú programok élete több szakaszra osztható. Brian Foote ezeket a sza- 
kaszokat a prototípus-készítési, bővítési, illetve konszolidációs jelzőkkel illeti (Foo92]. 


A prototípus-készítési szakasz számos tevékenységet foglal magába; mindazokat a tevé- 
kenységeket, amelyek révén a szoftver az első változat fokozatos bővítésével, módosításá- 
val lassan eléri a ,nagykorúságot", vagyis képessé válik arra, hogy megfeleljen az előzete- 
sen támasztott követelményeknek. A program ekkor általában olyan osztályhierarchiákból 
épül fel, amelyek szorosan illeszkednek az előzetes terv által meghatározott fogalmakhoz. 
Az ebben a szakaszban alkalmazott újrahasznosítás többnyire öröklés útján megvalósított 
, fehér dobozos" újrahasznosítás. 


Amikor az immár nagykorú szoftvert működésbe helyezik, további fejlesztését két egymás- 
nak ellentmondó szükséglet határozza meg: (1) a szoftvernek további követelményeket 
kell kielégítenie, miközben (2) még inkább újrahasznosíthatóvá kell válnia. Az új követel- 
mények általában új osztályok és műveletek, esetleg teljes osztályhierarchiák hozzáadását 
igénylik, vagyis a szoftver egy bővítési szakaszon megy át. E szakasz ugyanakkor nem 
nyúlhat túl hosszúra, mert különben a szoftver túlságosan rugalmatlanná, a későbbi változ- 
tatásokkal szemben túl nehézkessé válhat. Az osztályhierarchiák e szakaszban áttörik az 
előzetes terv által támasztott korlátokat, más fogalomkörökre is kiterjednek, az osztályok 
pedig számos önálló műveletet és példányváltozót is meghatároznak. 


Ahhoz, hogy továbbfejlődhessen, a program újjászervezésére van szükség: e folyamatot ne- 
vezik újraépítésnek (refaktorizáció). A keretrendszerek rendszerint ebben a szakaszban 
lépnek a képbe. Az újraépítés magába foglalja osztályok általános és szakosított célú össze- 
tevőkre bontását, műveletek feljebb vagy lejjebb léptetését az osztályhierarchiában, illetve 
osztályfelületek ésszerűsítését is. Ezen konszolidációs szakaszban számos új objektum jön 
létre, gyakran a meglevők felbontásával, illetve öröklés helyett objektum-összetétel haszná- 
latával, tehát a , fehér dobozos" újrahasznosítást felváltja a , fekete dobozos" újrahasznosí- 
tás. Az a folyamatosan fennálló igény, hogy újabb és újabb követelményeknek kell megfe- 
lelni, illetve még több kódrészletet lehessen újrahasznosítani, az objektumközpontú szoft- 
vert a bővítés és konszolidáció körforgásába helyezi. 
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nagyobb újrahasznosítás 


konszolidáció 


Az ábrán is látható ciklus kialakulása elkerülhetetlen, de a jó tervezők tisztában vannak az- 
zal, milyen változások kényszeríthetik ki az újraépítést, és ismerik azokat az osztály- és ob- 
jektumszerkezeteket is, amelyek segíthetnek az újraépítés elkerülésében. A követelmények 
alapos elemzése fényt deríthet arra, mely igények változnak majd meg nagy valószínűség- 
gel a szoftver élete során; a jó programszerkezet pedig felkészül ezekre a változásokra. 


Tervezési mintáink számos, az újraépítés következményeként előálló szerkezetet megra- 
gadnak; ha a mintákat a fejlesztés korai szakaszában alkalmazzuk, segítségükkel elkerülhe- 
tő a későbbi újraépítés, de még abban az esetben is hasznosak, ha a rendszer felépítésének 
befejezéséig nem tudjuk, hogyan alkalmazzuk őket — ekkor a rendszer módosításának 
módját mutathatják meg. 


6.2 Egy kis történelem 


A gyűjtemény összeállítását Erich kezdte el, Ph.D. szakdolgozatához [Gam91, Gam92], 
melyben az itt bemutatott minták mintegy fele kapott helyet. Az OOPSLA "91 idejére már hi- 
vatalosan is önálló katalógussá vált, Richard pedig csatlakozott Erich-hez, hogy együtt dol- 
gozzanak rajta. John nem sokkal később csatlakozott. Ralph az OOPSLA "92 idejére lett 
a csoport tagja. Keményen dolgoztunk, hogy az ECOOP "93-ra közzétehető állapotba hoz- 
zuk a gyűjteményt, de hamar rájöttünk, hogy egy kilencven oldalas dolgozatot ott nem mu- 
tathatunk be, ezért kivonatot készítettünk belőle, és azt nyújtottuk be. El is fogadták. Rövid- 
del ezután úgy döntöttünk, a katalógust könyvvé alakítjuk. 
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A tervezési minták neve az idők során némileg változott: a Burkolóból (Wrapper) Díszítő 
(Decorator) lett, a Ragasztóból (Glue) Homlokzat (Facade), a Pasziánszból (Solitaire) Egy- 
ke (Singleton), a Sétálóból (Walker) Látogató (Visitor). Néhány mintát elvetettünk, mert 
nem tűntek eléggé fontosnak. Ezektől eltekintve azonban a gyűjtemény többé-kevésbé vál- 
tozatlan maradt 1992 vége óta, bár maguk a minták rengeteget fejlődtek. 


Észrevenni, hogy valami mintát alkot, könnyű. Mind a négyen régóta dolgozunk objektum- 
központú rendszerekkel, így tudjuk, hogy ha valaki elég sok rendszert látott már, rögtön ki- 
szúrhatja a tervezési mintákat. A minták leírása azonban sokkal nehezebb, mint megtalálásuk. 


Ha rendszereket építünk, majd visszatekintünk rájuk, látjuk a mintákat munkánkban, de 
úgy leírni azokat olyanok számára, akik nem ismerik őket, hogy megértsék működésüket 
és fontosságukat, nagyon nehéz. A szakemberek már korai formájában felismerték a gyűj- 
temény jelentőségét, de csak azok értették meg a mintákat, akik már alkalmazták őket. 


Miután a könyv egyik fő célkitűzése az volt, hogy a kezdő fejlesztőknek megtanítsuk az ob- 
jektumközpontú tervezés mikéntjét, tudtuk, hogy érdekesebbé kell tennünk a katalógust. 
Az egyes mintákat leíró átlagosan két oldalt egy-egy részletes példával és saját munkára ösz- 
tönző mintakóddal tíznél is többre bővítettük. Azt is belevettük a kötetbe, hogy az egyes min- 
ták alkalmazásának milyen területei, illetve milyen hátrányai vannak. Mindez a könnyebb ta- 
nulást segíti. 


Egy másik fontos szempont, amely felé a könyv megírása során eltolódott a hangsúly, az 
volt, hogy bemutassuk a problémát, amit az adott minta megold. Egy probléma megoldása- 
ként gondolni rá, vagy olyan módszerként, amelyet újra és újra felhasználva egy adott fel- 
adathoz igazíthatunk, megkönnyíti a minta megtanulását. A problémakör, illetve annak le- 
írása, hogy milyen összefüggésben bizonyul az adott minta a legjobb megoldásnak — vagyis 
hogy mikor megfelelő -, persze jóval nehezebb. Általában véve mindig könnyebb tudni, 
mit csinál valaki, mint tudni, hogy miért — a , miért" pedig a tervezési minták esetében 
a megoldandó problémát jelenti. A minta alkalmazási céljának ismerete igen fontos, hiszen 
ennek alapján választhatjuk ki, melyik mintát is kell felhasználnunk, de a már létező rend- 
szerek felépítésének megértésében is segít. A tervezési minta kidolgozója tehát meg kell, 
hogy határozza, és le kell, hogy írja a problémát, amit az adott minta megold — még ha 
a megoldás felfedezése után is. 


6.3 A tervezési minták közössége 


Nem mi vagyunk az egyetlenek, akik szakemberek által használt tervezési mintákat leíró 
gyűjteményeket állítanak össze: egy nagyobb közösséghez tartozunk, melynek tagjait álta- 
lában véve a minták, különösképpen pedig a szoftverminták érdeklik. Christopher Alexan- 


der például az első építész volt, aki tanulmányozta az épületekben és közösségekben fel- 
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lelhető mintákat, és az ilyen minták alkotására kifejlesztett egy ,mintanyelvet". Munkája 
mindnyájukra nagy hatással volt, ezért érdemes röviden összevetni a mi eredményeinket az 
övéivel. Ezután másoknak a szoftverminták terén végzett kutatásaira is kitérünk. 


Alexander mintanyelvei 

Munkánk sok szempontból hasonlít Alexanderére. Mindkettő meglevő rendszerek vizsgá- 
latára és bennük minták keresésére épül. Mindkettő sablonokat alkalmaz a minták leírására 
(bár a mi sablonjaink teljesen más jellegűek). Mindkettő hétköznapi nyelven, sok-sok pél- 
dával mutatja be a mintákat, nem formális nyelvek segítségével, és mindkettő leírja, mire 
adnak választ az egyes minták. 


Mindazonáltal eltérések is jócskán adódnak: 


1. Házakat több ezer éve épít az emberiség, így rengeteg klasszikus példa áll előttünk, 
amelyekből meríthetünk. A szoftverrendszerek építése azonban viszonylag rövid 
időre tekint vissza, és , klasszikussá" sem túl sok vált közülük. 

2. Alexander sorrendet állít fel a minták alkalmazására; mi nem tettük. 

3. Alexander mintái a hangsúlyt a megoldandó problémára fektetik, míg a mi tervezési 
mintáink a megoldást írják le részletesebben. 

4. Alexander állítása szerint mintáiból teljes épületek építhetők fel. Mi nem állítjuk, 
hogy mintáink teljes programokat adnak ki. 


Amikor Alexander azt állítja, hogy pusztán mintái egymás utáni alkalmazásával megtervez- 
hetünk egy házat, ugyanaz a cél lebeg a szeme előtt, mint azoknak az objektumközpontú 
tervezési módszertant oktató szakembereknek, akik szigorú szabályokat állítanak fel a ter- 
vezés lépéseire. Alexander persze nem tagadja a kreativitás szükségességét. Egyes mintái 
megkövetelik, hogy ismerjük azoknak az embereknek a szokásait, akik majd az épületet 
lakják, a tervezés ,költészetébe" vetett hite pedig arról árulkodik, hogy a mintanyelv isme- 
rete önmagában nem jelenti a tudás teljességét". Mindazonáltal leírása arról, hogyan építik 
fel a minták a teljes szerkezetet, világossá teszi, hogy a mintanyelvek a tervezési folyamatot 
körülhatárolhatóbbá és egyszerűen megismételhetővé tehetik. 


Alexander nézőpontját alapul véve a tervezést befolyásoló ,erőkre" összpontosítottunk. 
Hatására igyekeztünk jobban megérteni, hogyan és milyen következményekkel alkalmaz- 
hatók tervezési mintáink, formális ábrázolásuk miatt viszont nem aggódtunk. A formális áb- 
rázolás természetesen segíthetné a minták alkalmazásának automatizálását, de jelen pilla- 
natban sokkal fontosabb, hogy feltárjuk a tervezési minták működését, mint hogy formali- 
záljuk őket. 


Alexander meghatározása szerint az e könyvben bemutatott minták nem alkotnak minta- 
nyelvet. Ha a manapság készített szoftverrendszerek változatosságára gondolunk, beláthat- 





! Lásd: The poetry of the language (AIS477]. 
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juk, hogy nehéz is lenne egy , teljes" mintakészletet összeállítani, ami az alkalmazások ter- 
vezéséhez lépésről lépésre vezető utasításokat ad. Egyes programfajták — például a jelen- 
téskészítő vagy űrlapos programok — esetében persze ezt is megtehetjük, de ez a katalógus 
csak egymáshoz kapcsolódó minták gyűjteménye, nem teljes mintanyelv. 


Igazság szerint úgy gondoljuk, valószínűleg soha nem is lesz teljes mintanyelv szoftverrend- 
szerek számára, bár olyat mindig lehet készíteni, ami teljesebb a korábbiaknál. Ilyen kiegé- 
szítést jelenthetnek például a keretrendszerek és használatuk [Joh92], a felhasználói felület 
tervezési mintái [BJ94], az elemzési minták [Coa92], illetve a szoftverfejlesztés más szempont- 
jai. A tervezési minták csupán egy szeletét jelentik egy nagyobb , szoftver-mintanyelvnek" . 


Szoftverminták 


Első közös élményünket a szoftverépítés kutatásának területén az OOPSLA "91-en, a Bruce 
Anderson által vezetett műhelyben szereztük, amely egy szoftverépítőknek szánt kézi- 
könyv kidolgozásán fáradozott. (Bár a , Szoftverépítők enciklopédiája" név jobban illett vol- 
na rá.) A műhelynek folytatása is lett; számos találkozó követte, például 1994 augusztusá- 
ban az első, a programok mintanyelveivel foglalkozó konferencia. Ennek hatására jött létre 
a szoftvertervezési tapasztalatokat dokumentálni kívánó közösség. 


Természetesen mások is tűztek ki hasonló célokat. Donald Knuth munkája, a The Art of 
Computer Programming (A számítógép-programozás művészete) [Knu73] — bár az algorit- 
musok leírására összpontosított — egyike volt az első kísérleteknek, amelyek a tapasztalatok 
egybegyűjtésére irányultak. A feladat azonban túlságosan hatalmasnak bizonyult ahhoz, 
hogy a végére lehessen érni. Egy másik, szintén az algoritmusokat középpontba helyező 
tervezésmódszertani gyűjtemény volt a Graphics Gems sorozat [G1a90, Arv91, Kir92], míg az 
Egyesült Államok hadügyminisztériuma által támogatott Domain Specific Software 
Architecture program IGM92] vizsgálatának tárgyát az architektúrákkal kapcsolatos infor- 
mációk képezték. A tudás alapú szoftverfejlesztéssel foglalkozó közösség a szoftverrend- 
szerekkel általánosságban kapcsolatos tudást gyűjti össze, és még számos csoport célja ha- 
sonlít legalább egy kicsit a miénkre. 


James Coplien Advanced Cst: Programming Styles and Idioms (C--4- haladóknak: progra- 
mozási stílusok és nyelvjárások) [Cop92] című könyve ugyancsak hatással volt ránk. Az ő 
mintái a mieinknél sokkal jobban kötődnek a C---- nyelvhez, és a kötet több alacsonyszintű 
mintát is tartalmaz, de számos átfedés található, amit könyvünkben jeleztünk is. Jim a min- 
tákat kutató közösség munkájában aktívan részt vesz; jelenleg a szoftverfejlesztő szerveze- 
tekben dolgozó emberek szerepének leírásával foglalkozik. 


Számos más helyen is találhatunk mintaleírásokat. Kent Beck volt az első, aki felhívta 
a szoftverfejlesztők figyelmét Christopher Alexander munkájára. 1993-ban cikksorozatot in- 
dított a The Smalltalk Report-ban a Smalltalk mintáiról. Peter Coad is jó ideje gyűjti a mintá- 
kat; a róluk írt dolgozata [Coa92] — számunkra legalábbis úgy tűnik — leginkább elemzési 
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mintákat tartalmaz. Legutóbbi munkáját e könyv írásakor még nem láttuk, de tudjuk, hogy 
újabb mintákon dolgozik. Tudomásunk van több folyamatban levő könyvről is, amelyek 
a mintákkal foglalkoznak (többek között a Pattern Languages of Programs konferenciáról is 
megjelenik majd egy), de még ezeket sem volt alkalmunk szemügyre venni, így csak annyit 
tehetünk, hogy tudatjuk az Olvasóval, újabb munkák várhatók e témában. 


6.4 Meghívó 


Mit tehetünk, ha érdeklődünk a minták iránt? Először is használjuk őket, és keressünk ma- 
gunk is a munkánkhoz illő mintákat. Az elkövetkezendő években rengeteg könyv és cikk 
lát majd napvilágot e témában, így a keresést számos forrás segítheti. Emellett célszerű elsa- 
játítani a tervezési minták nyelvezetét, és a tervezéssel kapcsolatos viták során munkatársa- 
inkkal használni. Gondolkodjunk a minták fogalmaiban. 


Másodszor, legyünk kritikusak. Ez a tervezésiminta-gyűjtemény nem csupán a mi kemény 
munkánk eredménye, hanem azon több tucatnyi kritikusé is, akik észrevételeikkel segítet- 
tek minket. Ha az Olvasó észrevesz egy hibát, vagy úgy érzi, egy ponton részletesebb ma- 
gyarázatra lenne szükség, ne habozzon kapcsolatba lépni velünk. Ugyanez persze bármely 
más mintagyűjteményre is érvényes: mondjuk el véleményünket a szerzőknek! A tervezési 
minták egyik nagy előnye, hogy alkalmazásuk révén a tervezési döntések nem ösztönösen 
születnek, így pontosan megfogalmazhatjuk, mit miért javaslunk. Ebből következik, hogy 
a minták hibáira is könnyebb rámutatni és a szerzővel vitába szállni. Éljünk a lehetőséggel! 


Harmadszor, fedezzük fel a saját magunk által használt mintákat, és írjuk le azokat. Legyen 
ez a programdokumentáció része, amit megmutatunk másoknak is. A minták felfedezésé- 
hez nem kell kutatónak lennünk, sőt, a lényeges minták megtalálása szinte lehetetlen, ha 
nem rendelkezünk kellő gyakorlati tapasztalattal. Nyugodtan összeállíthatjuk saját minta- 
gyűjteményünket is, ha van valaki, aki segít gatyába rázni őket. 


6.5 Búcsúzóul 


A legjobb tervek számos tervezési mintát használnak fel, amelyek egymással összefonódva 
segítik sikerre a terv egészét. Ahogy Christopher Alexander mondja: 


Építkezhetünk úgy, hogy a mintákat lazán összefűzzük: ekkor az épület önálló mintákból 
áll majd. Nem lesz , sűrű", nem lesz , mély". De ha a mintákat úgy rakjuk össze, hogy több 
is átfedje egymást ugyanazon a teren belül, az apró tér számos jelentést rejt majd, és ezek 
sűrű szövedékéből az épület mélységet nyer. 


A Pattern Language l(AIS-477, xli. oldal] 


Szószedet 


aláírás (szignatúra) Egy művelet neve, paraméterei és visszatérési értéke, 


alosztály Másik osztálytól öröklő osztály. A C---ban az alosztályt származtatott osztálynak 
(derived class) hívják. 


alrendszer Adott feladatkört együttműködve ellátó osztályok független csoportja. 
altípus Egy típus akkor altípusa egy másiknak, ha felülete tartalmazza a másik típus felületét, 
átruházás (képviselet, delegáció) Megvalósítási módszer, amelyben az objektumok más objek- 


tumokhoz továbbítják vagy más objektumokra ruházzák át egyes kérelmek végrehajtását. 
A megbízott az eredeti objektum nevében végzi el a kért műveletet. 





barát osztály A C--t nyelvben olyan osztály, amely egy másik osztály adataihoz és művele- 
teihez ugyanolyan jogosultságokkal rendelkezik, mint maga a tulajdonos osztály. 


csatolás Annak foka, hogy az egyes szoftverösszetevők mennyire függnek egymástól. 


destruktor (megsemmisítő függvény) A C-t nyelvben olyan művelet, ami minden esetben au- 
tomatikusan meghívódik amikor egy objektum törlésére kerül sor. 


dinamikus kötés vagy késői kötés Kérelem futás közbeni összekapcsolása egy objektummal, 
illetve annak egy műveletével. A Ct---ban csak a virtuális függvények késői kötésűek. 


egységbe zárás vagy betokozás Ábrázolás és megvalósítás objektumba rejtésének eredmé- 
nye. Az ábrázolás így nem látható és az objektumon kívülről közvetlenül nem elérhető; el- 
érése és módosítása kizárólag műveleteken keresztül lehetséges. 
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együttműködési diagram (interakció-diagram) Diagram, amely a kérelmek útját ábrázolja az ob- 
jektumok között. 


elemkészlet Osztálygyűjtemény, amely hasznos szolgáltatásokat biztosít, de nem határozza 
meg egy alkalmazás szerkezetét. 


elvont csatolás Ha adott egy A osztály, amely a B elvont osztályra hivatkozik, azt mondjuk, 
A elvontan csatolt B-hez. Ezt azért hívjuk elvont csatolásnak, mert az A egy bizonyos objek- 
tumtípusra, és nem konkrét objektumra hivatkozik. 


elvont művelet Olyan művelet, amely megad egy adott aláírást (szignatúrá) , de annak meg- 
valósítását nem tartalmazza. A Csi nyelvben az elvont művelet megfelelője a tisztán virtuális 
tagfüggvény. 


elvont osztály Olyan osztály, amelynek elsődleges feladata egy felület meghatározása. 
Az elvont vagy absztrakt osztály megvalósításának egy részét vagy egészét alosztályokra 
bízza. Nem példányosítható. 


fehér dobozos újrahasznosítás Osztályöröklésen alapuló újrahasznosítási módszer, melynek 
során egy alosztály felhasználja szülőosztályának felületét és megvalósítását, de hozzáfér- 
het a szülő egyébként rejtett adataihoz is. 


fekete dobozos újrahasznosítás Objektum-összetételen alapuló újrahasznosítási módszer. 
Az összetett objektumok nem fedik fel belső felépítésüket egymás számára, ezért hasonlít- 


ják őket a repülők fekete dobozához. 


felület (interfész) Egy objektum műveletei által meghatározott aláírások (szignatúrák) 
összessége. A felület azon kérelmek halmazát írja le, amelyeket az objektum teljesíthet. 


felülírás vagy felülbírálás (Szülőosztálytól örököl? művelet új meghatározása egy alosztályban. 
fogadó (vevő) Kérelem célobjektuma. 


ismeretség (ismeretségi viszony) Az az osztály, amely egy másik osztályra hivatkozik, ismeret- 
ségi viszonyban áll a másik osztállyal, vagyis ismerőse annak. 


kérelem Az objektumok akkor hajtanak végre egy műveletet, amikor egy másik objektum- 
tól a műveletnek megfelelő kérelem érkezik. A kérelem gyakran használt másik neve az 
üzenet. 
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keretrendszer Együttműködő osztályok halmaza, amelyekből egy bizonyos szoftvertípus 
számára újrahasznosítható terv készíthető. A keretrendszer a szoftver szerkezetét elvont 
osztályokra bontja, meghatározza azok felelősségi körét, illetve a közöttük levő kapcsolato- 
kat, ezáltal útmutatást ad a program felépítéséhez. A fejlesztő a keretrendszert úgy szabhat- 
ja egy adott alkalmazásra, hogy a keretosztályokból példányokat és alosztályokat hoz létre, 


konkrét osztály Elvont műveletekkel nem rendelkező osztály, amely példányosítható. 


konstruktor (létrehozó függvény) A C---- nyelvben olyan művelet, amelynek meghívására új 
példányok létrehozásakor automatikusan sor kerül. 


metaosztály Az osztályok a Smalltalk nyelvben objektumok. A metaosztály az osztályobjek- 
tumok osztálya. 


mixin osztály vagy bekeveredő (bekevert) osztály Olyan osztály, amelyet más osztályokkal va- 
ló, öröklésen keresztüli együttműködésre terveztek. A mixin osztályok általában elvontak. 


művelet Az objektumokban tárolt adatokat csak az objektum műveletei érhetik el. E műve- 
letek végrehajtására akkor kerül sor, amikor az objektumhoz kérelem érkezik. A C----ban 


a műveleteket tagfüggvényeknek hívják, a Smalltalk a metódus kifejezést használja. 


objektum Futásidejű egyed, amely mind az adatokat, mind az adatokon műveleteket végző 
eljárásokat tartalmazza. 


objektumdiagram Diagram, amely egy adott objektumszerkezetet ábrázol futásidőben. 
objektumhivatkozás Más objektumot azonosító érték. 


objektum-összetétel Objektumok , összeszerelése", melynek célja összetettebb viselkedés ki- 
alakítása. 


osztály Az osztály határozza meg egy objektum felületét és megvalósítását, valamint az 
osztály adja meg az objektum belső ábrázolását, illetve azokat a műveleteket, amelyeket az 
objektum végrehajthat. 


osztálydiagram  Osztályokat, azok belső szerkezetét és műveleteit, illetve az osztályok kö- 
zötti statikus kapcsolatokat ábrázoló diagram. 


osztályművelet Olyan művelet, amely nem egy önálló objektumra, hanem egy osztályra irá- 
nyul. A C4--ban az osztályműveletek megfelelői a statikus tagfüggvények. 
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öröklés Olyan kapcsolat, amely egy egyedet egy másikhoz viszonyítva határoz meg. Az osz- 
tályöröklés egy vagy több szülőosztályból állít elő egy új osztályt, amely felületét és megva- 
lósítását a szülőktől örökli. Az új osztályt alosztálynak vagy (a C-t--ban) származtatott osztály- 
nak hívjuk. Az osztályöröklés a felületöröklést és a megvalósítás-öröklést egyesíti: az előbbi egy 
új felületet ír le egy vagy több már létező felület segítségével, míg az utóbbi egy új megva- 
lósítást, már létező megvalósítások alapján. 


őstípus  Szülőtípus, amelytől egy másik típus örököl. 


összesítő kapcsolat Az összesítő objektum viszonya az őt alkotó részekhez. A példányok (az 
összesítő objektumok) részére ezt a kapcsolatot az osztály határozza meg. 


összesítő objektum (aggregát objektum, aggregátum) Olyan objektum, amely alobjektumokból 
épül fel. Az alobjektumok az összesítő objektum részei, melyekért az aggregátum felelős. 


paraméterezett típus. Olyan típus, amely egyes összetevő típusait nem határozza meg ponto- 
san; ezeket használatkor paraméterként kapja meg. A C--4-ban a paraméterezett típusokat 
sablonoknak (template) hívják. 


példányváltozó Egy objektum ábrázolásának egy részét meghatározó adat. A C-t az adattag 
kifejezést használja rá. 


privát öröklés A C--4 nyelvben olyan osztály öröklése, amelynek kizárólag a megvalósításá- 
ra van szükség. 


protokoll A felület fogalmának bővítése a feldolgozható kérelmek sorozatával. 


szülőosztály Olyan osztály, amelytől egy másik osztály örököl. Szinonimái a szuperosztály 
(Smalltalk), az alaposztály (C----) és az ősosztály. 


tervezési minta A tervezési minták rendszerezik, elnevezik, és megmagyarázzák az objek- 
tumközpontú rendszereken belül gyakran ismétlődő megoldásokat. Leírják a problémákat, 
a rájuk adott válaszokat, illetve hogy a megoldás mikor alkalmazható, milyen következmé- 
nyekkel és mellékhatásokkal kell számolnunk, valamint ötleteket adnak és példát mutatnak 
a megvalósításra is. A megoldás a feladathoz illeszkedő osztályok és objektumok általános 
érvényű elrendezése, amit a megvalósítással együtt az adott környezethez kell igazítani. 


típus Egy adott felület neve. 


többalakúság (polimorfizmus) Az összeegyeztethető felületű objektumok futásidőben egy- 
mással való helyettesítésének képessége. 





Útmutató a jelölésekhez 


A könyv során a fontosabb fogalmak illusztrálására diagramokat használtunk. Egyesek , in- 
formálisak" voltak, például egy párbeszédablak képernyőképének vagy egy objektumfa se- 
matikus rajzának formáját öltötték. Maguk a tervezési minták azonban ennél formálisabb 
jelölésrendszert alkalmaznak az osztályok és objektumok közötti kapcsolatok bemutatásá- 
ra: ez a függelék ezt mutatja be részletesebben. 


Három különböző diagramtípust használtunk: 


1. Az osztálydiagramok az osztályokat, azok szerkezetét, valamint a közöttük levő stati- 
kus kapcsolatokat ábrázolják. 

2. Az objektumdiagramok egy adott objektumszerkezetet mutatnak be futásidőben. 

3. Az együttműködési diagramok (interakció-diagramok) a kérelmek útját mutatják az ob- 
jektumok között. 


Minden tervezési minta legalább egy osztálydiagramot tartalmaz, a többi alkalmazására ak- 
kor került sor, amikor a tárgyalás ezt megkívánta. Az osztály- és objektumdiagramok az 
OMT (Object Modeling Technigue) modellen alapulnak ÍRBP-91, Rum94l", az együttműkö- 
dési diagramok az Objectory [JCJO92], illetve a Booch módszeren [Boo94l. 


B.1 Osztálydiagramok 


A B.1 ábra az elvont és konkrét osztályok OMT jelölését mutatja. Az osztályokat egy doboz 
jelöli, amelynek felső részében az osztály vastag betűs neve olvasható. Az osztály kulcsmű- 
veletei az osztály neve alatt jelennek meg, ezek alatt pedig az esetleges példányváltozók. 





! Az OMT az osztálydiagramokra is objektumdiagram néven hivatkozik, mi ezt kizárólag az objektumszerkezete- 
ket ábrázoló diagramok részére tartottuk fenn. 
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A típusinformációk nem kötelezőek; mi a C--t programozók szokásait követjük, akik (a 
visszatérési típus jelzéséhez) a típus nevét kiteszik a művelet, a példányváltozó vagy a tény- 
leges paraméter neve elé. A dőlt betű arra utal, hogy az adott osztály vagy művelet elvont. 


Egyes tervezési mintákban segíthet, ha látjuk, hol hivatkoznak az ügyfélosztályok résztvevő 
osztályokra. Amikor a minta résztvevőként tartalmaz egy Ügyfél osztályt (vagyis annak 
a mintában felelősségi köre van), az Ügyfél szokványos osztályként jelenik meg. Ilyen pél- 
dául a Pehelysúlyú minta. Ha a mintának azonban nincsenek Ügyfél résztvevői (vagyis az 
ügyfeleknek nincs feladatuk a mintában), de feltüntetésük világosabbá teszi, mely résztve- 
vők lépnek kapcsolatba ügyfelekkel, az Ügyfél osztályokat a B.1b ábrához hasonlóan szür- 
ke betűkkel jeleztük. Erre a Helyettes mintánál láthatunk példát. A szürke jelzés azt is egy- 
értelművé teszi, hogy nem véletlenül maradt ki az Ügyfél a résztvevők tárgyalásából. 


A B.1c ábra különböző osztályok közötti kapcsolatokat mutat. Az osztályöröklés OMT jelö- 
lése az alosztályt (az ábrán VonalAlakzat) és szülőosztályát (Alakzat) összekötő háromszög. 
A része, illetve összesítés kapcsolatot ábrázoló objektumhivatkozást rombusz alapú nyílhe- 
gyű vonal jelzi, ami az összesített osztály (például az AlakzaD) felé mutat. Ha a nyílhegyű 
vonal végén nincs rombusz, akkor ismeretségi viszonyról van szó (például a VonalAlakzat 
egy Szin objektumra hivatkozik, amelyen a különböző alakzatok osztozkodhatnak). A hi- 
vatkozás nevét a kezdőpont közelében néhol feltüntettük, hogy megkülönböztessük más 
hivatkozásoktól.? 


Egy másik fontos dolog annak jelzése, mely osztályok példányosítanak más osztályokat. 
Ezt szaggatott nyílhegyű vonallal ábrázoltuk (az OMT nem támogatja). Ezt hívjuk , létrehoz- 
za" kapcsolatnak; a nyíl a példányosítás céljául szolgáló osztályra mutat. A B.1c ábrán 
a LétrehozóEszköz VonalAlakzat objektumokat hoz létre, 


Az OMT jelölése az , egynél több" fogalmára a teli kör. Ha ilyen kört látunk egy hivatkozás 
előtt, az azt jelenti, hogy több objektumra hivatkozunk, illetve több objektumot összesí- 
tünk. A B.1c ábra azt mutatja, hogy a Rajz több Alakzat típusú objektumot összesít. 


Végezetül, az OMT-t álkódos (pszeudokódos) jelzésekkel egészítettük ki, hogy felvázol- 
hassuk a műveletek megvalósítását. A B.1d ábra a Rajz osztály Rajzol műveletének álkód- 
ját tartalmazza. 





? Az OMT az osztályok között , asszociációkat" is meghatároz, amelyeket az osztályok dobozai között egyszerű 
vonalakkal jelez (az asszociációk kétirányúak). Bár elemzés közben hasznosak lehetnek, úgy éreztük, az asszo- 
ciációk túlságosan elvontak ahhoz, hogy a tervezési mintákban kapcsolatokat fejezzünk ki velük, hiszen a terve- 
zés során úgyis le kell majd őket fordítanunk objektumhivatkozásokra vagy mutatókra. Az objektumhivatkozá- 
sok emellett befelé irányulnak, így jobban megfelelnek a minket érdeklő kapcsolatok számára. (A Rajz például 
ismeri az Alakzat objektumokat, az Alakzatok azonban nem ismerik az őket tartalmazó Rajzot. Ezt a viszonyt 
nem lehet pusztán asszociációkkal kifejezni.) 
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B.2 Objektumdiagramok 


Az objektumdiagramok kizárólag példányokat ábrázolnak; a tervezési minta objektumai- 
nak pillanatfelvételét. Az objektumnak az , egy Valamf" nevet adtuk, ahol a , Valamf" az ob- 
jektum osztálya. Az objektumok jele a könyvben (némileg eltérően a szabványos OMT-től) 
a lekerekített sarkú , doboz" (négyszög), amelyben az objektum nevét vonal választja el az 
esetleges objektumhivatkozásoktól. A hivatkozott objektumokra nyilak mutatnak. Az ob- 
jektumdiagramra a B.2 ábrán láthatunk példát. 

















ElvontOsztály Név KonkrétOsztályNév 
ElvontMűvelett() Művelet1() 
Típus ElvontMűvelet2() Típus Művelet2() 
példányváltozó! 
Típus példányVáltozó2 








(a) Elvont és konkrét osztályok 


get 


(b) Résztvevő Ügyfél osztály (balra) és rejtett Ügyfél osztály (jobbra) 

















VonalAlakzat Szín 


LétrehozóEszköz ]-------------.--- pl 


(c) Osztálykapcsolatok 





























Rajz 
for minden alakzat ( 
Rajzoll) Or femme meeneesnnee] alakzat-5 Rajzol() 
) 
(d) Álkódos jelölés 
B.1 ábra 


Az osztálydiagramok jelölései. 
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egyRajz 


alakzat[0] 
alakzat[1] 


( egyVonalAlakzat ) ( egyKörAlakzat ) 


B.2 ábra 
Az objektumdiagramok jelölései. 











































egyLétrehozóEszköz egyRajz AgyV/onalálákzat 
new VonalAlakzat 
DNÁÁANNÁNÁG KÉK PEKÉK ÉNEKESE KEKEKEBI ÉRE SET ERTN ESEN MENÉS KERETÉT, s 
HozzáadfegyVonalAlakzat) Frissítí) 
áz 
e 
B.3 ábra 


Az együttműködési diagramok jelölései. 


B.3 Együttműködési diagramok 


Az együttműködési diagramok a kérelmek végrehajtásának sorrendjét mutatják az objektu- 
mok között. A B.3 ábrán levő diagram azt mutatja, hogyan adunk egy alakzatot egy rajzhoz. 


Az együttműködési diagramon az idő fentről lefelé , folyik"; egy-egy objektum élettartamát 
folytonos függőleges vonal jelzi. Az objektumok elnevezésére ugyanazok a szabályok vo- 
natkoznak, mint az objektumdiagramoknál, vagyis az osztály neve elé az ,egy" kerül (pl. 
egyAlakzaD. Ha egy objektum példányosítására csak a diagram által rögzített időpont után 
kerül sor, ezt szaggatott függőleges vonallal jelezzük, ami a létrehozási pontig tart. 
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Azt, hogy egy objektum aktív, vagyis kérelmet szolgál ki, a rövidebb oldalára állított (, füg- 
gőleges") téglalappal jelöljük. A művelet más objektumokat is felkérhet, ezeket a kérelme- 
ket a fogadó objektumra mutató vízszintes nyilak mutatják; a kérelem nevét a nyíl felett 
tüntetjük fel. Az objektum létrehozására irányuló kérelmeket szaggatott nyílhegyű vonallal 
jelezzük, az olyanokat pedig, amelyek magára a küldő objektumra vonatkoznak, visszaka- 
nyarodó nyíllal. 


A B.3 ábra azt mutatja, hogy az első kérelem az egyLétrehozóEszköz-től érkezik, és az 
egyVonalaAlakzat létrehozására irányul. Később az egyVonalAlakzat ,Hozzáad"-ódik az 
egyRajz-hoz, e művelet pedig az egyRajz-ot arra kéri, hogy saját magának küldjön egy 
Frissít kérelmet. Megfigyelhetjük azt is, hogy az egyRajz a Rajzol kérelmet a Frissít művelet 
részeként küldi el az egyVonalAlakzat-nak. 





Alaposztályok 


Ebben a függelékben azokat az alaposztályokat ismertetjük, amelyeket az egyes tervezési 
mintákhoz mellékelt C-t--- példakódokban használtunk. Szándékosan egyszerűek és számu- 
kat is szándékosan tartottuk alacsonyan. A következő osztályokról van szó: 


e List — objektumok rendezett listája. 

s Iterator — egy összesítő objektum (aggregátum) objektumainak sorrendben törté- 
nő elérésére szolgáló felület. 

e ListIterator - bejáró a List bejárásához. 

e Point -— kétdimenziós pont. 

e Rect - tengelyekhez igazított téglalap. 


A Ct4 egyes újabb szabványos típusait nem minden fordítóprogram ismeri. Amennyiben 
a bool esetében ez a helyzet, határozzuk meg ezt a típust magunk: 


typedef int bool; 
const int true - 1; 
const int false - 0; 


C.1 List 


A List osztálysablon alapszintű tárolót biztosít objektumok rendezett listájának tárolására. 
Az elemeket érték szerint tárolja, ami azt jelenti, hogy a beépített típusokkal ugyanúgy mű- 
ködik, mint az osztálypéldányokkal. A Listcint5 például egészek (int) listáját adja meg. 
Mindazonáltal a legtöbb minta a List-et arra használja, hogy objektumokat címző mutató- 
kat tároljon - ilyen például a List-Glyph"5 —, ezért a List heterogén listákhoz nem al- 
kalmazható. 
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A kényelem kedvéért a List a veremműveletekhez szinonimákat is biztosít, így a List-et 
vermekhez használó kódban nem kell új osztályt meghatároznunk, ami áttekinthetőbbé te- 
szi a programot. 


template cclass Items 
elass List ( 
public: 
List(long size - DEFAULT LIST CAPACITY) ; 
List(Listf£); 
"akt Éve 
Listg operator-(const List6); 


long Count() const; 

Itemg Get(long index) const; 
Itemg First() const; 

Itemg Last() const; 

bool Includes(const Itemg) const; 


void Append(const Item); 
void Prepend(const Itemf£); 


void Remove(const Itemé); 
void RemoveLast(); 

void RemoveFirst(); 

void RemoveAl1 () ; 


Item Top() const; 
void Push(const Itemgr); 
Itemg Pop(); 

); 


A következőkben a fenti műveleteket részletesebben is bemutatjuk. 
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Létrehozás, megsemmisítés, előkészítés és értékadás 


List(long size) 
Előkészíti (inicializálja) a listát. A s ize (méreD) paraméter az elemek kezdeti számára utal. 


List(List6) 
Felülbírálja az alapértelmezett másoló konstruktort az adattagok megfelelő előkészítéséhez. 


-List() 
Felszabadítja a lista belső adatszerkezeteit, de a lista elemeit nem. Az osztályból nem szár- 


maztathatók alosztályok, ezért a destruktor nem virtuális. 


List§ operator-(const List£) 
Megvalósítja az értékadó műveletet az adattagoknak megfelelő értékadáshoz. 


Elérés 
Ezek a műveletek a lista elemeinek alapszintű elérését biztosítják. 


long Count() const 
A listában levő objektumok számát adja vissza. 


Itemg Get(long index) const 
A megadott sorszámú (indexű) objektumot adja vissza. 


Itemg First() const 
A lista első objektumát adja vissza. 


Items Last() const 
A lista utolsó objektumát adja vissza. 


Hozzáadás 


void Append(const Itemf) 
Az argumentumot a listához adja, annak utolsó elemeként (append - hozzáfűz). 


void Prepend(const Item6) 
Az argumentumot a listához adja, annak első elemeként (prepend - eléfűz). 
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Eltávolítás 


void Remove(const Itemsz) 


A megadott elemet eltávolítja a listából (remove - eltávolít). A művelet megköveteli, hogy 
a listában levő elemek típusa támogassa az -- összehasonlító operátort. 


void RemoveFirst() 
Eltávolítja az első elemet a listából. 


void RemoveLast () 
Eltávolítja az utolsó elemet a listából. 


void RemoveAll() 
Minden elemet eltávolít a listából. 
Veremfelület 


Itemg Top() const 
A legfelső elemet adja vissza (amikor a listát veremként kezeljük). 


void Push(const Itemf) 
Az elemet a verem tetejére helyezi. 


Itemg Pop() 
Az elemet leveszi a verem tetejéről. 


C.2 Iterator 


Az Iterator az összesítő objektumok bejárási felületét meghatározó elvont osztály. 


template cclass Item: 
class Iterator ( 


public: 
virtual void First() - 0; 
virtual void Next() - 0; 


virtual bool IsDone() const - 0; 
virtual Item Currentltem() const - 0; 
protected: 
Iterator(); 
1; 
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A műveletek szerepe a következő: 


virtual void First() 
A bejárót az aggregátum első objektumára állítja. 


virtual void Next() 
A bejárót a sorozat következő objektumára állítja. 


virtual bool IsDone() const 
Igazat (true-0) ad vissza, ha a sorozatban már nincs több objektum. 


virtual Item CurrentIltem() const 
A sorozat aktuális pozícióján álló objektumot adja vissza. 


C.3 Listiterator 


A ListIlterator az Iterator felület megvalósítása listaobjektumok bejárásához. 
Konstruktora argumentumkérnt a bejárandó listát várja. 


template cclass Item: 
class Listlterator : public Iteratorcitems; ( 
public: 

ListIlterator(const Listcitemost aList); 


virtual void First(); 

virtual void Next(); 

virtual bool IsDone() const; 

virtual Item Currentltem() const; 
1; 


C.4 Point 


A Point egy pontot jelképez egy kétdimenziós derékszögű koordináta-rendszerben. Alap- 
szintű vektorszámítási képességekkel rendelkezik. Az egyes pontok koordinátáit a követ- 
kezőképpen határozza meg: 


typedef float Coord; 


A Point műveletei önmagukért beszélnek. 


class Point ( 
public: 
static const Point Zero; 
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bh; 


Point (Coord x - 0.0 Coord y - 0.0); 


Coord X() const; void X(Coord x); 
Coord Y() const; void Y(Coord y); 


friend Point operatort(const Pointg, const Point6); 
friend Point operator-(const Pointg, const Point€); 
friend Point operatort(const Pointg, const Pointf£); 
friend Point operator/(const Pointő, const Point6); 


Pointg operatort-(const Pointf£); 
Pointg operator--(const Pointf£); 
Pointg operatort-(const Pointf£); 
Point§ operator/-(const Pointf); 


Point operator-(); 


friend bool operator--(const Pointg, const Point6); 
friend bool operator!-(const Point, const Point6); 


friend ostreamg operatorcc(ostreamg, const Point6); 
friend istreamg operators5(istreamág, Point6); 


A Zero statikus tag jelentése Point (0, 0). 


C.5 Rect 


A Rect egy tengelyekhez igazított téglalapot jelképez, amelyet kezdőpontja és kiterjedése 
(extent, vagyis a szélessége és a magassága, Width és Height) határoz meg. A Rect 
műveletei sem igényelnek külön magyarázatot. 


class Rect ( 
public: 


static const Rect Zero; 


Rect(Coord x, Coord y, Coord w, Coord h); 
Rect(const Pointg origin, const Pointő§ extent); 


Coord Width() const; void Width(Coord) ; 
Coord Height() const; void Height(Coord) ; 
Coord Left() const; void Left(Coordá) ; 
Coord Bottom() const; void Bottom(Coord) ; 


Pointg Origin() const; void Origin(const Point6); 
Pointg Extent() const; void Extent(const Point6£); 
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void MoveTo(const Pointf£); 
void MoveBy(const Point6); 


bool IsEmpty() const; 
bool Contains(const Point6) const; 


hó 


A Zero statikus tag a következő négyszöggel egyenértékű: 


Rect(Point(0, 0), Point(0, 0)); 
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elemzés 65, 70, 187, 252 
elemzés egységbe zárása 71 
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elemző modell 12, 355 
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lemzőgenerátor 252 
érAktuális 66 
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fogadható üzenetek 220 
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lenálló bejáró 266 
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őállítkód 341 
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Elvontlista 263, 271 
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Encapsulator 220 
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értesítés 226, 299 

értesítő felület 282 

érvényes adatok 326 

Érvényesítő 326 

érvényesítő stratégiák 326 

esemény 286 

események 182 

eseménykezelés 347 

eseménykezelő 236 

eseménykezelő viselkedés 182 

esetágakat tartalmazó függvények 168 








Established 307 

Eszköz 117, 315 

eszközkészlet 28 

eszközleltár 342 

eszközpaletta 117 

eszköztípusok 342 

ETvr 95, 105, 116, 121, 127, 151163, 
175, 185, 194, 209, 236, 247, 285, 
306, 325 

ETt-4 szövegépítő-blokk 220 

ET4-4Draw 151 

etgdb 127 

ETProgrammingEnvironment 194 

Evaluate 257 

Event-Handler 236 

Execute 61, 238, 241, 245, 246, 292 

expect 206 

expression 248 

ExpressionNode 192, 193 

ExtendedHandler 232 

extent 211 


Fa 145 

Facade 9, 187, 358 

Factory Method 6, 9, 106 
FaElérőKépviselő 147 

fájl 185, 195 

fájlnév 211 

fájlrendszer 128 
FájlRendszerEgyed 147 
FájlRendszerFelület 195 

fák 172 

fákon végzett alapműveletek 261 
false 257 

FaNézet 145, 146 

faszerkezet 165 

faszerkezetű aggregátumok 268 
fehér doboz 20 

fehér dobozos újrahasznosítás 20, 356 
fekete doboz 20 
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ekete dobozos újrahasznosítás 20, 356 


adat 7, 247 

bontás 164 

cserélhető algoritmuscsaládok 12 
dolgozElem 273 

dolgozó műveletek 220 

elősségi körök 140, 177, 225 
elősséglánc 8, 18, 23, 169, 176, 225, 
226, 227, 230, 237, 247, 348, 350 
használó oldali gyorstárazás 116 
használói események 236 

jasználói felület 2 

használói felület elemei 209 
iasználói felület finomítása 43 
használói felület tervezési mintái 
360 
használói felületi díszítők 183 
nasználói felületi elemek 151 
nasználói felületi elemkészlet 154, 
175, 185 
jasználói műveletek 59 

használói műveletek engedélyezése 
185 
old 293 
oldóÁllapot 288 

soroló állandó 308 

szabadítás 267 

tételágak 318 

tételes utasítások 232, 309 
ülbírálás 16, 271, 283 

ület 14, 149, 157 

ület egyszerűsítése 194 

ület megfelelősége 181 

ületek közötti kapcsolatok 15 
ületi elemkészlet 86 
ületillesztés 145, 152 
ületöröklés 17 

ülírandó műveletek 331 

ülírás 16, 39, 62, 107, 170, 183 
ülírt műveletek 20 

















Figure 109 
Figyelő 296, 307, 314 


eStream 185 


FileSystemlnterface 195 
FileSytemEntity 147 
FilteringListlterator 263 
FilteringListTraverser 274 
FinomítottElvontÁbrázolás 156 
finomság 12, 14 

First 66, 263, 269, 270 
FixedStack 153 

fizikai szerkezet 35 
Flyweight 9, 196, 201 
FlyweightFactory 201 
főablak 226 

Fogad 334, 337, 339 

fogadó 227, 238, 241, 243, 350 
fogadó objektum 21 

fogadó objektumok 226 
fogadó-művelet pár 238 
fogalmi rétegek 299 
foglalás gyűjtőtárból 325 
fogyasztás 173 

fókusz 331 

Folyam 185, 219, 276 
folyam objektumok 185 
folyamat 12, 195 
folyamosztály 185 
folytatások 266 

Font 206 
FontDialogDirector 278, 284 
fordítási egység 131 
fordítási függőségek 190 





fordítási idejű megvalósítás-függőség 


157 
fordítási idejű szerkezet 24 
fordítási idejű típusellenőrzés 24 
Fordító 188 
fordítói alrendszer 187, 193 
fordítói kódoptimalizáló 325 
fordítóprogram 77, 261, 333 
fordított keresés 65 
fordított vezérlési szerkezet 330 
formális ábrázolás 359 
formális nyelvek 359 


Programtervezési minták 





formázás 40 

formázási parancsok 198 

formázó algoritmus egységbe zárása 
41 

formázott kiíratás 333 

forrásregiszter 175 

framework 28 

Fresco Application Toolkit 347 

friend 267, 269 

Frissít 300, 301 

Frissít művelet argumentuma 301 

Frissít művelet paramétere 300 

frissítendő terület 237 

frissítés 286, 300 

rissítések láncolata 299 

Frissítő felület 298 

funktor 247 

futáshosszú kódolás 185 

futási sebesség 197 

futásidejű környezet 120 

utásidejű körülmények 225 

futásidejű pillanatfelvétel 285 

futásidejű szerkezet 24 

futásidejű típusellenőrzés 168 

futásidejű típusinformációk 232, 247, 

347 

függő objektum 296 

függőség 12 

függőségek 189, 296 

függőségi feltételek 299 

függőségi rendszer 300 

függőségi viszony 131 

függvény 11 

függvényhívó operátor 247 

függvényobjektum 247 


G, Gy 


gc 206 
GdbAdaptor 127 
GenerateCode 341 
gépfelépítés 193 





gépi CAD 28 

gépi kód 193 

gépi utasítások 191 
GetButtonLayout 209 
GetCharCode 73 

GetChild 176 
GetComposite 171 
GetCurrent 66 

GetExtent 142, 211, 218 
GetMaze 101 
GetMenuBarlLayout 209 
GetMisspellings 74 
GetSelection 283 
GetSubclasses 145 
GetSubdirectories 145 
GetWidth 182 
GetWindowlmp 163 
globális hozzáférési pont 128 
globális környezet 251 
globális névtér 191 

globális objektumok konstruktorai 131 
globális táblázat 127 
globális változó 128, 129 
globális változók 339 

Glue 358 

Glyph 38, 199, 203, 208 
GlyphContext 204 
GlyphContext::GetFont 204 
GlyphContext::Next 204 
GlyphFactory 207 

Glyphs 175 

GNU gdb 127 

Goldberg 126 

gomb 48, 209, 229, 237, 277, 283 
görbék 57 

gördítősáv 43, 48, 87, 178, 209, 237 
görgetés 177 
GörgetésDíszítő 179 
görgetési képesség 184 
Görgetéslde 179 

gráf 202 

Grafika 117, 166, 211 
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GrafikaGyár 136 

grafikai alapelemek 165 

fikai jellemző 203 

ikai rendszer 166 

ikus alkalmazás 165 

fikus díszítés 185 

fikus elem 234, 235 

grafikus felhasználói felület 185, 226, 
2 
fi 


afikus felhasználói felületi 
elemkészlet 177 

grafikus frissítés 236 

grafikus objektumok 199 

grafikus osztályok 217 

grafikus szerkesztő 28, 287 

grafikus vezérlő 277 

grafikus vezérlők elvont alaposztálya 
282 

GrafikusEszköz 117, 136 

Graphic 151, 166, 211, 217 

GraphicBlock 151 

GraphicTool 117 

Graphics 117, 175 

Graphics Gems 360 

GraphicsFactory 136 

gyakran ismétlődő megoldás 2 

gyár 158 

Gyár módszer 106 

gyárak 49 

gyárak mint egykék 90 

gyárobjektum 136 

Gyártó metódus 106, 107 

Gyártófüggvény 6, 9, 19, 94, 96, 106, 
107, 264, 276, 332 

gyártófüggvény felülírása 90 

Gyártófüggvény minta 96, 120, 136 

gyártófüggvények 116, 330 

gyermek 166 

gyermekek elérésére szolgáló felület 
169 

gyermekek halmaza 171 

gyermekek sorrendje 172 











gyermekelemek 168 

gyermekfüggő műveletek 166 

gyermekkel nem rendelkező képjel 68 

gyermekkezelő felület 170 

gyermekkezelő műveletek 170 

gyermekkezelő műveletek bevezetése 
170 

gyermekmutató 171 

gyermekobjektumok 193 

gyűjtemény 276, 294, 337 

gyűjtemény egységbe zárásának 
megsértése 295 

gyűjtemény mérete 158 

gyűjtemények 267 

gyűjteményosztály 157 

gyűjteményosztály-könyvtár 276 

gyűjteményosztályok 28 

gyűjtőtár 198 


hagyományos programnyelvek 354 
halmaz 163, 337 

hálózati kapcsolat 307 

hamis 62, 257 

Handle 158, 163 
Handle/Body 153, 158 
HandleBufferFull 185 
HandleHelp 228, 229, 231, 233 
HandleMouse 217, 218, 284 
Handler 231 

HandleReguest 231, 232 
hangjegy 117 

hardver 26 
hardver-architektúrák 193 
háromdimenziós helyszínek 347 
hasáb 35 

hash 158, 172, 300 

HasHelp 233 

HashSet 163 

HashTable 163 

hasítótábla 172 


Programtervezési minták 





használó kapcsolat 24 
hatékonyság 140, 250 
hatékonyságnövelés 253 
hatókör 11 
ház 342 
help topic 233 
HelpHandler 228, 229, 231, 233 
helyes tervezés 355 
helyesírás 70 
helyesírás-ellenőrzés 65, 70 
Helyettes 9, 15, 116, 139, 210, 213, 222 
helyettes másolása 214 
Helyettes minta 153, 214 
Helyettes tervezési minta 212, 267 
helyettesdíszítő 223 
Helyettesítő 210 
helyettes-szerkezet 213 
helyettestípusok 214 
helyi állapotinformáció 314 
helyi másolat 218 
helyőrző 210 
helyreállítás 240, 287 

elytelenül írt szavak 65 
hibahalmozódás 243 
hibakeresési információ 185 
hibakereső 127 
hibakereső-felületi alkalmazás 127 
Hibakeresőlllesztő 127 
hibakezelés 216 
Hid.8, 23, 153, 155, 221 
Híd minta 140, 153 
Híd tervezési minta 58, 154 
hierarchikus felépítésű információk 36 
hierarchikus logikai szerkezet 209 
hi-fi berendezés 172 
hiperszöveges dokumentumok 355 
ívási verem 268 
Hivatkozás 213 
hivatkozási lánc 231 
hivatkozás-számlálás 156, 157, 203 
hivatkozásszámláló 158, 214 
Hívó 241 








Hollywood elv 330 

Homlokzat 9, 12, 187, 189, 196, 222, 
286, 358 

Homlokzat minta 140, 188, 190 

hook 109, 329 

HookoOperation 330 

hordozhatóság 3, 47 

horizontális bejárás 268 

horog 109, 329 

horogműveletek 330 

hosszú eljárások 309 

hosszú feltételes utasítások 309 

HotDraw 315 

Hozamgörbe 325 

Hozzáad 169, 170, 176 

hozzáférés-szabályozás 220 

hozzáférés-vezérlés 331 

húzó modell 301 

HyphenationVisitor 75 


1/0 185 

IBM Presentation Manager 154 
IconDockWindow 161 
IconWindow 54, 154, 160 
idiómák 354 

idő 304, 318 

időzítő 304 

if 309 

igaz 62, 257 

igény szerint 210 

igények 25 

IkonAblak 54, 154, 160 
ikongyűjtemény 318 

ikonok 160 

ikontárolók 161 

Illesztendő 144 

illesztendő kifejezés-csomópont 346 
illesztési folyamat 254 

Illesztő 8, 141, 144, 186, 220, 221 
Illesztő minta 139, 164 
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Image 211, 217 
ImageProxy 211, 218 
ImagePtr 214 
immutable 172 
Implementor 157 
implicit receiver 227 
index 207, 270 
IndexedCollection 257 
indexelés 39 
Initialize 116, 122, 124 
inline 272 
INORDER 66, 265, 268 
inorder bejárás 65 
inputState 254, 345 
inputState argumentum 346 
Insert 39, 66 
InspectClass 194 
InspectObject 194 
Instance 129, 130, 131, 133, 314 
Instrument 325 
integrált áramkör 173 
integrált áramkörök 326 
interaction technigue library 127 
Interactor 151 
interakció-diagram 7 
interaktív eljárások 127 
interaktivitás 109 
interest 301 
Interpret 250, 251 
Interpreter 9, 225, 248 
Intersects 39, 199 
InterViews 95, 135, 151, 175, 185, 208, 
247, 306, 322, 325 
Intéző 289, 290 
InvalidateRect 236 
invariáns 169, 331 
Inventory 344 
InventoryvVisitor 344 
Invoker 241 
IONA Technologies 116 
irányító 97, 98, 279, 282 
irányított körmentes gráf 209, 302 


IRIS Inventor 347 

IsDone 66, 263, 268, 270, 294 

IsEmpty 150 

ismeretség 24 

Ismert felhasználások 8 

Ismét 62 

ismételt végrehajtás 240 

IsmétlésKifejezés 249, 250 

IsMisspelled 74 

Item 338 

ItemType 294 

IterationState 294 

Iterator 4, 9, 67, 173, 226, 262, 263, 
268, 338 

Iterátor 262 

IteratorOutofBounds 270 

IteratorPtr 272 

Ivan Sutherland Sketchpad 126 


James Coplien 360 

Javít 323 

jelentéselemző eljárás 105 
jelentéskészítő 360 
jelentéstani ellenőrzés 265 
jelölések 8 

jelölési rendszer 354 

jelölt 226 

jelölt objektumok 225 

jó programszerkezet 357 
Johnson 315, 328 


kapcsolatban álló objektumok 296 
kapcsolati kötések 286 
kapcsolattartási minták 349 
kapcsolattartási viselkedés 351 
kapcsoló 173 

Kapcsolódó minták 8 
Kapcsolódva 307, 314 
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karakter 35, 196, 199 
karakterfolyam 191 
karakterkészletek 197 
karakterkód 198, 203, 209 
karakterkódokkal indexelt táblázat 203 
karakterlánc ábrázolás 156 
karakterlánc-minták 248 
karakterláncos ábrázolás 163 
karaktersorozat 185, 253 
ártyák 172, 342 
atalógus 90 
Kent Beck 360 
kényelmi házasság 153 
Kép 166, 211 
kép igény szerint 210 
KépesMegnyitDokumentum 328 
képhelyettes 210, 211 
Képjel 199, 203 
épjel-betűtípus hozzárendelés 204 
képjelek 38 
képjelfüggő bejárók 68 
KépjelGyár 207 
Képjelkörnyezet 204 
képjeltípusok 70 
képmegvalósítás 164 
képviselet 21, 27 
képviselő 21, 147, 195, 210 
Képviselő objektumok 147, 152 
kérelem 11, 60, 64, 232 
érelem egységbe zárása 60 
érelem kezelése 226 
kérelem teljesítése 230 
kérelem továbbítása 180 
kérelemobjektumok 232 
kérelem-paraméterek 232 
kérelemtovábbítás 221 
érelmek 213 
kérelmek ábrázolása 231 
kérelmek halmaza 232 
kérelmek kódolása 351 
kérelmek teljesítése 226 
kérelmet kibocsátó ügyfél 228 











kérelmező objektum 227 

keresés 65, 132, 172 

keresési idő 207 

kereső algoritmus 248 

keresztkapcsolatok 278 

keretrendszer 28, 116, 175 

keretrendszerek 106, 356, 360 

keretrendszerrel meghatározott elvont 
gyárak 134 

KérFelhasználó 244 

KernelProxy 212 

keskeny felület 146, 289, 291 

keskeny híd 163 

későbbi felhasználás 185 

késői kötés 14 

Kész 66, 263, 268, 270 

KészítAjtó 123 

KészítFal 123 

Készlet 86 

KészülMegnyitDokumentum 328 

két felület egymáshoz illesztése 146 

kétdimenziós táblázat 347 

kétirányú illesztő 145 

kétirányú osztályillesztő 146 

kétszeres öröklés 180 

kettős közvetítés 340, 347 

kettős szegély 180 

kezdeményező 288, 289 

kezdő tervező 1 

kezdőérték 122 

kezdőpont 149 

kezdőszimbólum 248 

KezelEgér 284 

Kezelkérelem 231 

kezelő 229, 230, 231 

KezelSúgó 228, 229, 231 

kiegészítő szolgáltatások 177 

kiegyensúlyozott fák 263 

kifejezés 248 

KifejezésCsomópont 192 

kifejezett felület-meghatározás 147 

kifejezett hivatkozás 300 
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kifejezett osztálymegadás 26 
kifejezett szülőhivatkozások 169 
kifinomultabb hivatkozás 212 
Kiír 270 

KiírAlkalmazottak 270 

kind 66 

Kinézet 209 

kirajzolás 209 
kisebb gyűjtemények 158 
kisméretű objektum 181 

Kit 86, 95 
kiterjedés 211 

ivételezett hozzáférés 267 
kivonattáblák 163, 172 
lónok előkészítése 122 
Klónoz 117, 121, 136 
lónozás 122 
kód megkettőzésének elkerülése 221 
ódba , drótozott" művelethívás 231 
kód-előállítás 187, 253, 265 
kódkettőződés 328 
kódoptimalizáló 333 
ód-újrahasznosítás 329 
Kofler 267 
Kolléga 281 
Kolléga osztályok 281 
ollégák 351 
kommunikáció 225 
Kompozíció 165 
Kompozit 165 
konkrét gyár 90 

onkrét Létrehozó 110 
konkrét megvalósítás 156 
konkrét műveletek 26, 330 
konkrét osztály 16 
KonkrétAlany 298 
KonkrétÁállapot 308 
KonkrétBejáró 205 
KonkrétDíszítő 180, 181 
KonkrétElem 180, 222, 336, 337 
KonkrétÉpítő 98, 99 
KonkrétGyár 88, 94 








Konkrétkezelő 230 
KonkrétKözvetítő 281 
Konkrétlátogató 336 
KonkrétLétrehozó 108 
KonkrétMegfigyelő 298 
KonkrétMegvalósító 156, 157, 158 
KonkrétOsztály 329 
KonkrétöÖsszesítő 265 
KonkrétParancs 241 
KonkrétPehelysúlyú 201 
KonkrétPrototípus 119 
KonkrétStratégia 319 
KonkrétTermék 88, 108 
konnektorok 286 
konstruktor 49, 85, 102, 104, 112, 122, 
131, 133, 150, 183, 194, 208, 234, 
245, 258, 313 
konstruktorhívás 48 
konstruktornak átadott paraméterek 
157 
konszolidáció 356 
kooordinátarendszer 237 
korlátfeltételek 268 
korlátlan szintű visszavonás 240 
kottaszerkesztő 117 
kottavonal 117 
kölcsönös függőségek 280 
költség 197 
költséges objektumok 210 
Könnnyűsúlyú 253 
könyvelőrendszer 128 
KönyvtárFaNézet 146, 147 
könyvtárszerkezet 146 
KönyvtárTallózó 147 
kör 136 
KörGyár 136 
körkörös függőségek 190 
körkörös hivatkozás 121 
környezet 204, 250, 251, 308, 319 
környezet állapota 311 
környezetfüggő állapot 140 
környezetfüggő helyi menü 240 
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környezetfüggő információk 199 
környezetfüggő program 26 
környezetfüggő súgó 226 
környezeti változó 127, 134 


381 

KötésFeloldó 287, 292 
kötésfeloldó rendszer 287 
következetesség 140 
következmények 3, 7 
Következő 66, 263, 266, 270 
következő elem 228 
követő 228 
közös bejárási felület 263 
közös Elem osztály 181 
közös előtag 331 
közös viselkedés 278 
KözösFal 102 
köztes frissítések 300 

öztes réteg 278 
közvetett elérés 221, 222 
közvetettség 225 
közvetítés 281 
Közvetítő 9, 23, 225, 277, 278, 281, 

303, 306, 348, 349, 351 

Közvetítő minta 196, 280 
közvetítő objektum 23, 225 
közvetlen elérés 222 
Közzététel—Előfizetés 296, 297 
közzétevő 297 
kreativitás 359 
upacra helyezett bejáró 267 
kurzor 262, 266 
kurzor alapú bejáró 268 
urzor alapú bejárók 276 
küldő 227, 350 
küldő-fogadó kapcsolat 350 
ülső állapot 197, 201 
ülső állapot eltávolítása 202 
külső állapotinformációk azonosítása 
202 
külső állapotinformációk raktára 204 








kötelezően felülírandó alapműveletek 


külső bejáró 266, 268, 341 
külső bejárók 274 


labirintus 82, 84, 91 

LabirintusÉpítő 100 

labirintusépítő művelet 101 

LabirintusGyár 91 

LabirintusPrototípusGyár 122 

lánc 226 

láncolt lista alapú megvalósítás 158 

láncolt listák 163, 172 

laphiba 195 

láthatatlan befoglalás 44 

látható elemek 178 

LáthatóElem 179 

Látogat 336, 339 

LátogatÉrtékadás 334 

LátogatKonkrétElem 339 

Látogató 4, 10, 14, 15, 22, 75, 176, 193, 
226, 252, 261, 333, 334, 336, 348, 
358 

Látogató tervezési minta 76, 261, 335 

LátogatváltozóHivatkozás 334 

Látszat 187 

Layout 209 

Layoutkit 95 

laza csatolás 26, 29, 190, 225, 277, 281, 
349 

lazy initialization 113 

Leaf 168 

lebegő eszközpaletták 160 

lefelé irányuló átalakítás 94, 125 

lefelé irányuló típusátalakítás 91 

legalMessages 220 

Leíró 153, 158, 163 

leképezés 347 

leltárkészítő látogató 344 

LeltárLátogató 344 

lemezmeghajtó 173 

lemezre mentett objektumok 111 
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Lempel-Ziv 185 

enyitható menü 60 

éptető match: művelet 256 
LeromboltFal 93 
LeromboltlabirintusGyár 93 
étező felület 222 

étrehozási folyamat 100 
étrehozási minta 137 
étrehozási minták 10, 19, 81 
étrehozási objektumminták 11 
étrehozási osztályminták 11 
LétrehozBejáró 68, 173, 264, 271 
LétrehozDokumentum 107 
LétrehozFájlPárbeszédablak 109 
LétrehozGördítőSáv 87 
LétrehozKarakter 208 
LétrehozlLabirintus 92 
LétrehozMódosító 142 
Létrehozó 108 
LétrehozÖsszetettLabirintus 102 
LétrehozVezérlők 280, 283 
eválasztás 298 

.evél 167 

evél képjel 68 

evélhez való hozzáadás 171 
evélobjektum 167 

Lá 33 

Lezárva 307, 314 

ibgtt könyvtár 163 
Lieberman 247 

Line 165, 166 

LineFactory 136 

LineShape 141 

LinkedlList 163 

LinkedSet 163 

List 262, 268 

Lista 262 387 

ListaBejáró 68, 262, 269 
listák 68 

listamező 278, 283 
listamező feltöltése 284 
ListBox 283, 285 











Listening 307 

Listlterator 68, 174, 262, 269, 271, 272 
ListTraverser 273 

literal 248 

literál 248 

LiteralExpression 249, 254, 345 
literális karakterlánc 254 
Literálkifejezés 249, 250 

Load 122, 219 

Loadlmage 215 

logikai változók 257 

Look 209 

look-and-feel standard 47 
Lookup 132 

lusta előkészítés 113, 131 


M 


MacApp 114, 116, 181, 182, 236, 331 
Macintosh 52, 331 
MacroCommand 176, 239, 244, 246 
magasabb szintű felület 187 
magasabb szintű műveletek 156 
magasság 149, 211 

magic token 349 

mágikus jel 349 

make: metódus 90, 125 
MakeColor 95 

MakeDoor 123 

MakeFont 95 

MakeWall 123 

MakeWindow 95 

MakróParancs 176, 239, 242 
Manipulator 109, 142, 149 
MapsSite 83, 125 

maradandó kötés 153, 155 
maradandó objektum 212 

Mark Linton 347 

Marriage of Convenience 153 
más felületre történő átültetés 190 
második alapelv 21 

Másol 259 
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másolás 121 

másolás íráskor 214 

másoló konstruktor 121, 124 
match: 254, 346 
matematikai egyenletek 287 
matematikai kifejezések 333 
Maze 84 

MazeBuilder 100, 101 
MazeFactory 91, 122, 133 
MazeGame 84 
MazePrototypeFactory 122 


McCullogh 220 

Mediator 9, 225, 277, 281 

megbízott 311 

Megfigyelő 5, 9, 18, 226, 286, 296, 297, 
298, 349 


Megfigyelő minta 286, 297, 299, 306 
Megfigyelő tervezési minta 282 
megfigyelőfüggő frissítési protokoll 
301 

Megfordítható 62 

meghajtó 342 

meghajtók 172 

meghajtóprogram 2 

Megjelenít 331 

megjelenítés 296 

megjelenítési mód 209 
megjelenítési módszerek 296 
megjelenítési szabvány 47, 86 
megjelenítési szabványok 209 
megjelenítési szabványoktól való 
függetlenség 209 

meglevő hivatkozások 231 
meglevő objektumhivatkozások 231 
Megnyit 307 

MegnyitDokumentum 327 
MegnyitParancs 239 

megoldás 3 

megosztás 169, 196, 202 
megosztható objektumok 220 
megosztott állapotinformációk 202 
megosztott levél-csomópont 202 





megosztott objektum 197 
megosztott objektumok kezelése 202 
megosztott stratégiák 321 
megosztott törzsű leírók 158 
Mégse 62, 243 
megsemmisítés 311 
Megvalósítás 8, 140, 149, 153, 157, 321 
megvalósítás részletei 157 
megvalósítás-függőség 19 
megvalósítási függőség 21 
megvalósítási függőségek 53, 310 
megvalósítási modell 355 
megvalósítás-öröklés 18 
Megvalósító 156, 157 
megvalósító osztály 156 
megvalósítók megosztása 158 
Megváltozott 283 

mellékhatás 202, 220 
mélymásolás 120 
mélymásolat 121 

Memento 9, 287 

memóriában tárolt karakterlánc 185 
memóriafoglalás 325 
memóriakezelés 163 
memória-objektum 195 
memóriaszivárgás 272 
MemoryObject 195 
MemoryObjectCache 195 
MemorysStream 185 

Ment 122, 219 

Menu 238 

MenubarlLayout 209 
Menultem 238 

menü 48, 209, 237, 238, 277 
MenüElem 238 

Message 219 

metaosztály 135 

metódus 11 

metódushívások 220 
metódus-kikeresés 216 
metódusválasztó 286 

Metszi 199 





Tárgymutató 


409 





Meyer 153 

minta neve 3, 7 

minták leírása 358 

mintanyelv 359 

mixin 17, 228, 234, 271 

Mode Composer 127 

Model 4, 306 

Model/View/Controller 226 

Modell 4, 226 

modell állapota 226 

modell—nézet-vezérlő 116, 226, 306 

Model-View-Controller 4 

Módosító 109, 142 

mondatok 248 

MonodGlyph 45 

Motif 47, 86 

MotifLook 209 

MotifVezérlőGyár 87 

MotifWidgetFactory 87 

MoveCommand 292 

mozgató művelet 288 

MozgatParancs 292 

működés kibővítése alosztályokkal 27 

multi-metódus 4 

Murray 267 

MutatPárbeszédablak 280 

művelet 14, 237 

művelet felülírása 27 

művelet neve 336 

műveletek 11, 347 

műveletet kezdeményező objektum 
242 

műveleti függvény 247 

műveletvégző képjelek 60 

művelet-visszavonás 240, 287, 288 

művészi rajzolás 28 

MVC 4, 306 

MyClass 246 

MyCreator 111 

MyCreator: :Create 112 

MyProduct 111 

MySingleton 133 

MyType 339 





N, Ny 


nagy finomságú objektumok 196 

nagy számú objektum 199 

nagy szoftverrendszerek 190 

Nagyító 237 

nagykövet 212 

nagyméretű raszterképek 210 

NamesSingletonPair 132 

natural size 322 

nem karakter képjelek 208 

nem módosuló 172 

nem soros elérésű gyűjtemény 276 

nem virtuális tagfüggvény 331 

NemMegosztottkKonkrétPehelysúlyú 
201 

nemterminális szimbólum 251 

nemterminális szimbólumok 257 

NemterminálisKifejezés 251 

nested generalizations 156 

NetPrice 174 

NettóÁr 174 

névadási szabályok 114 

NévEgykePár 132 

nevesített változó 258 

névtelen függvények 266, 272 

névterek 191 

new művelet 131 

NewGraphic 136 

Next 66, 204, 263, 266, 270, 294 

NeXT AppkKit 152, 164, 236, 331 

nextAvailable: 256 

NEXTSTEP 147, 212, 220 

Nézet 4, 5, 160, 226, 331 

nézetek 181, 306 

nézetkezelő 285 

nil 219 

Node 333 

NodevVisitor 334 

NonterminalExpression 251 

NormálMéretParancs 239 

NormalSizeCommand 239 

not 257 
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Notify 299, 304 objektum belső állapota 287 

NullBejáró 68, 268 objektum belső részei 181 

Nulllterator 68, 173, 268 objektum felülete 14 

nullmutató 170 objektum módosítása 212 

null-műveletek 194 objektum teljes szolgáltatásköre 223 

NXBitMaplmageRep 164 objektumfelületek 14 

NXBrowser 152 objektumhoz való hozzáférés 220 

NXCachedlmageRep 164 objektumillesztő 142, 144, 150, 153 

NXEPSImageRep 164 objektumklónozás 121 

NXImage 164 objektumkompozíció 20 

NXImageRep 164 objektumközpontú programozás 354 

NXProxy 212, 220 objektumközpontú rendszer 175 

nyelvi támogatás 291 objektumközpontú szövegszerkesztők 

nyelvjárások 354 196 

nyelvtan 225, 248, 354 objektumközpontú tervezés 355 

nyelvtan megvalósítása 252 objektumközpontú tervezési minták 3 

nyelvtani ellenőrzés 65 objektum-létrehozás 48 

nyelvtani szabály 249 objektum-létrehozási minták 81 

nyelvtani szabályok 252 objektummegvalósítás 15 

nyilvános 149 objektumminták 11, 221 

nyilvános alrendszeri osztályok 191 objektumok 11, 355 

nyilvános felület 191 objektumok azonossága 181 

nyilvántartó 121, 132 objektumok felelősségi körökkel való 

nyomkövetési információ 185 bővítése 180 

nyomtatás 227, 236 objektumok közötti függőségek 226 

nyomtatási kép 233 objektumok közti függőségek 190 

nyomtatási párbeszédablak 236 objektumok megosztása 140 

nyomtatási sor 128 objektumok összesítése 24 

NyomtatásPárbeszédablak 227 objektumokhoz való hozzáférés 210 

nyomtató 128 objektumonkénti belső 

nyújthatóság 322 állapotinformációk 202 

jan a objektum-összetétel 20, 27, 117, 136, 

0 0 0 Ó 139, 143, 166, 186, 221, 225, 356 

[A [A [A objektumprotokoll 281 

Object 125, 220 objektumszerkezet 333, 337 

Object gyökérosztály 303 objektumszerkezet bejárása 341 

Object Modeling Technigue 7 objektum-tulajdonság 199 

Objective C 90, 120, 147 Observable 306 

Objects for States 307 Observer 5, 9, 226, 296, 297, 298, 303, 

ObjectWindows 276, 326 304, 306 

ObjectWorksVSmalltalk 145, 152, 185, Okos helyettes 212, 214 


194 okos mutató 212 
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oldalikon 60 

OlvasFolyam 276 
olvasóprogram 96 

OMT 7 

on: osztálymetódus 126 
OOPSLA "91 357, 360 
OOPSLA "92 357 

Opdyke 328 

Open 307 

OpenCommand 239, 244 
OpenDocument 327, 332 
OpenLook 209 

operátor 215 

operatorO 247 

operator" 272 

operator-5 214, 272 
optimalizáló 325 

or 257 

óra 305 

Orbix ORB 116 
OrderedCollection 257, 276 
originator 288, 289 
ősosztály nélküli osztály 216 
őstípus 14 

oszlopdiagram 296 

osztály 15, 17 

osztály alapú minták 221 
osztályazonosító 111 
osztályba sorolás 10 
osztályhierarchia 225 
osztályillesztő 144, 149 
osztályillesztők 139 
osztálykönyvtár 236 
osztálykönyvtárak 329 
osztálylétrehozási minták 81 
osztálymetódus 129 
osztályminták 11 
osztályművelet 129 
Osztálynézet 116 
osztályobjektum 120 
osztályok ábrázolása 155 
osztályok dinamikus betöltése 120 
osztályok megvalósítása 157 


osztályok szervezése 222 

osztályokkal történő paraméterezés 
136 

osztályöröklés 16, 18 

osztálysablon 23, 245 

osztályváltozó 112 

önálló objektumok 166, 196 

önállóan tervezett osztály 221 

önhívás 140, 166 

önhívó felépítés 36 

önhívó összesítő szerkezetek 268 

önhívó összetétel 40, 153, 165, 222 

önhívó szerkezetek 276 

öröklés 11, 20, 153, 177, 221, 225, 252, 
320, 355, 356 

örökölt művelet 330 

örökölt műveletek 300 

Összeállít 325 

összeállítási modell 100 

Összeállító 41, 318 

összeállító utasítások 172 

összeegyeztethető felületek 38 

összeférhetetlen felületű osztályok 141 

összekötők 286 

összeomlás 240 

Összesítő 265 

összesítő objektumok 262 

összeszerkesztés 132 

Összetétel 6, 8, 12, 18, 20, 41, 106, 127, 
139, 165, 167, 168, 186, 192, 202, 
203, 209, 222, 237, 261, 268, 276, 
318, 337, 347 

Összetétel minta 165, 166, 172, 175, 
231, 242, 252, 261, 342 

Összetétel tervezési minta 40, 106 

összetételek 268 

összetételek bejárása 176 

Összetett 165 

összetett aggregátumok 265 

összetett frissítések 286 

összetett frissítések egységbe zárása 
302 

összetett képjelek 207 
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összetett objektum 6 
összetett objektumok 96 
összetett protokoll 136 
összetett szerkezet 166 
ÖsszetettElem 340 
ÖsszetettEszközök 173 


paletták 161 

PaletteWindow 161 

Pane 285 

paraméter 8, 14, 23, 60, 66, 70, 85, 91, 
94, 101, 111, 152, 194, 199, 226, 
240, 273 

paraméterek átadása 232 

paraméteres illesztő 148 

paraméteres műveletek 91 

paraméterezés 117, 240 

paraméterezett gyártófüggvény 
felülbírálása 111 

paraméterezett gyártófüggvények 111 

paraméterezett típusok 23 

Parancs 8, 14, 18, 61, 226, 237, 238, 
241, 292, 295, 349, 350 

Darancs minta 176, 240, 242, 247 

Parancs objektumok élettartama 240 

Parancs tervezési minta 64, 237 

parancselőzmények 63 

parancsok sorozata 239 

parancsösszetételek 242 

parancssorozatok 240 

PárbeszédAblak 54, 109, 161, 226, 235, 

277 

párbeszédablak bezárása 285 

Párbeszédablaklrányító 280 

párbeszédablakok 160, 326 

ParcPlace Smalltalk 185 

Parent 40 

párhuzamos 2 

párhuzamos osztályhierarchiák 109 

Parser 105, 187, 191 





parserClass 116 
parsing 252 
partCatalog 90 
Pascal 4 
Pascoe 220 
PassivityWrapper 185 
Paste 238 
PasteCommand 238, 244, 245 
Pasziánsz 358 
passzív 272 
Pásztázó 187, 191 
path 57 i 
Pehelysúlyú 9, 12, 181, 196, 201, 261 3 
pehelysúlyú grafikus objektumok 203 3 
pehelysúlyú levél-csomópontok 202 ! 
Pehelysúlyú minta 140, 176, 169, 197, 

199, 310, 316 3 
pehelysúlyú objektum 197 
pehelysúlyú objektumok 208 
pehelysúlyú objektumok megosztása 

200 
PehelysúlyúGyár 201, 202, 207, 209 
Példakód 8 
példány 16, 129, 131, 314 
példányok száma 202 
példányosítás 16, 137, 210, 217, 311 
példányosítási folyamat 81 
példányváltozó 310 
pénzforgalom 325 
pénzügyi elemző program 77 
pénzügyi eszközök 176, 325 
pénzügyi modellező alkalmazás 28 
perform:withArguments: 219 
perzisztens 222 
Peter Coad 360 
Picture 166 
pillanatfelvétel 288 
pluggable adapter 145 
PluggableAdaptor 152 
PM 48, 57, 161 
PMAblak 154 
PMlconWindow 154 
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PMIikonAblak 154 
PMvVezérlőGyár 87 
PMWidgetFactory 87 

PMWindow 154 

PMWindowlmp 161 

Point 161 

Policy 317 

polimorfizmus 14, 349 
PolygonShape 141 

Pont 161 

portfolió 176 

postfix 253 

POSTORDER 66 

PREORDER 66 

Presentation Manager 48, 52, 86, 161 
Preview 233 

Pricingvisitor 343 

primitív 35 

primitívek 165 

Print 227, 270 

PrintDialog 227 

PrintEmployees 270 
PrintNEmployees 274 

privát 149 

privát alrendszeri osztályok 190 
privát fejléc-állomány 157 

privát öröklés 18 

probléma 3 

procedurális 240 

process 195 

Processltem 273 
ProgramCsomópont 187, 192 
program-csomópont 192 
ProgramCsomópontÉpítő 187, 191 
programkörnyezet 26 
ProgrammingEnvironment 194 
ProgramNode 187, 192, 193 
ProgramNodeBuilder 105, 187, 191 
rogramNodeEnumerator 346 
programozási környezet 187, 194 
programozási nyelv alapelemei 191 
protected 267 





protokoll 286 

Prototípus 9, 19, 90, 116, 117, 119, 127, 
135, 136, 352 

prototípus klónozása 90 

Prototípus minta 96, 119 

prototípus-készítés 356 

prototípus-kezelő 120, 121 

prototípusobjektum 136 

prototípusok klónozása 120 

prototípusokra épülő nyelvek 121 

Prototype 9 

Proxy 9, 210, 213 

pszeudokód 17 

Publish-Subscribe 296 

pull model 301 

push model 301 

Putlnt 185 


0 


OOCA 261, 295 

OOCA kötésfeloldó elemkészlet 145, 
295 

gueue 276 


R 


Ragasztó 358 
RajzAlkalmazás 106, 327 
RajzDokumentum 106, 327 
rajzobjektum 109, 141 
Rajzol 166, 199, 211, 218 
rajzolási bejárás 202 
rajzolási kérelmek 179 
rajzolóprogram 165, 327 
RajzolTartalom 160 
RajzolTégla 161 
rajzszerkesztő 141 
RangevValidator 326 
RApp 326 

Read 111 

ReadStream 276 
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RealSubject 213 

realSubject metódus 219 

Receiver 241, 245 

Rectangle 39, 166 

Refactoring to generalize 328 

refaktorizáció 356 

régi felület 222 

Register 132 

RegisterAllocator 325 

RegisterTransfer 175 

RegisterTransferSet 176 

regiszter 175 

regiszterfoglalási módszer 77 

regiszterfoglalási sémák 325 

regular expressions 248 

RegularExpression 249 

rejtett fogadó 227 

rekurzió 140 

rekurzív aggregátumok 268 

rekurzív ereszkedő 252 

rekurzív kompozíció 36, 165 

REMatchingvVisitor 345 

Remove 39, 169, 170, 171, 174, 176 

rendezett aggregátumok 267 

rendszer rétegezettsége 299 

rendszerfüggő ablakok 54 

rendszerfüggő jellemzők egységbe 
Zárása 158 

rendszerfüggő megvalósítás 155 

rendszerfüggő objektumok 163 

rendszerfüggő osztályok elrejtése 196 

rendszerösszeomlás 240 

rendszerparaméter 136 

Repair 323 

RepairFault 196 

repeat 253, 254 

RepeatExpression 345 

repetition 254 

RepetitionExpression 249, 254 

Replace 257 

Reguest 232 

ResetFocus 331 

Responder 236 


rész-egész viszony 166 
rész-egész viszonyok 165 
részegységek 172 
Résztvevők 7 

rétegezés 26, 157 
rétegezettség 350 
Reverselistlterator 270 
Reversible 62 

Rich Text Format 96 
RISCCodeGenerator 193 
RISCKódElőállító 193 
RISCscheduler 325 
Robson 126 

robusztus 267 

rokon algoritmusok 320 
rokon minták 10 

rokon műveletek 334, 335, 338 
rokon objektumok 222 
romantikus regény 2 
Room 82 

RoomNo 84 
RoomWithABomb 93, 124 
Router 326 

Row 199, 201, 204 
rögzített számú elem 153 
RTF 96 

RTF elem 96 
RTF-átalakító 105 
RTFOlvasó 96 
RTFReader 96 
RTF-vezérlőszó 96 

RTL 175 

RTLExpression 175 
rugalmas minták 12 
rugalmasság 3, 12, 221 
Rumbaugh 156 


S, Sz 


sablon 23, 70 

Sablonfüggvény 9, 116, 225, 301, 327, 
929352 

Sablonfüggvény tervezési minta 328 
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sablonfüggvények 328 
sablonok 113, 321, 359 
sablonosztály 321 
sablonparaméterek 321 
SajátOsztály 246 

Save 122, 219 

Scanner 187, 191 

scene 347 

ScrollbarLayout 209 
ScrollDecorator 178, 179, 184 
Scroller 46, 237 

ScrollTo 179 

sebesség 65 

sekély másolat 121 

Self 4, 21, 121, 311 
sémarögzítő rendszer 165 
SeguenceableCollection 257 
SeguenceExpression 249, 254, 345 
Service Configurator 105 
Session 135 

Set 163, 276 

Sétáló 358 

SetContents 184 

SetFocus 331 

SetMemento 293 

SetSide 94 

SetText 283 

SGML dokumentum 99 
SGMILOlvasó 99 
SGMLReader 99 

Shape 141, 148 
ShowDialog 280 
shrinkability 322 
SimpleChangeManager 302 
SimpleCommand 245 
SimpleCompositor 318, 324 
Single Static Assignment 175 
single-dispatch 341 
Singleton 9, 128, 130, 358 
SkipList 263, 271 
SkiplListlterator 271 

SkipTo 267 


Smalltalk 4, 18, 24, 25, 90, 94, 112, 120, 
121, 125, 129, 131, 147, 191, 216, 
219, 226, 233, 253, 261, 266, 276, 
303, 306, 341, 345, 360 

Smalltalk 80 135 

Smalltalk Model/View/Controller 175 

Smalltalk/V 257, 282, 286 

Smalltalk/V for Windows 282 

Smalltalk-80 4, 105, 175, 257, 346 

Smalltalk-80 Model/View/Controller 
116 

sok szabályból álló nyelvtan 252 

sok-sok kapcsolatok 281 

sokszög 35 

SokszögaAlakzat 141 

Solelnstance 131 

Solitaire 358 

Solve 293 

SolverState 288 

sor 35, 199, 276 

sorbejáró 276 

sormutató 262, 266 

soros elérésű gyűjtemény 276 

SorozatKifejezés 249 

sorszámozás 39 

sortávolság 109 

sortörés 40, 317 

sorzáró karakterek 76 

SPECTalk 261 

SpellingCheckingvisitor 75 

SpreadSheetApplication 327 

SpreadSheetDocument 327 

SOL 116 

SOLParser 116 

SSA 175 

StackMachineCodeGenerator 193 

StandardMazeBuilder 102 

State 9, 226, 307 

StatementNode 192 

StateVariable 145 

statikus hozzárendelés 175 

statikus kapcsolatok 348 


416 
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statikus nyelvek 121 

statikus objektum 133 

statikus osztályösszetétel 139 

statikus öröklés 158, 180 

statikus példány 133 

statikus tagfüggvény 129, 131 

statikus típusokkal dolgozó nyelv 147 

statikus típusokra épülő nyelvek 170 

statikus változó 273 

statikus védelem 291 

stílus 209 

stílusinformáció 209 

stílustáblázat 209 

storage 195 

Stratégia 6, 9, 12, 18, 22, 181, 186, 226 
317, 319, 332, 348 

stratégia alapú megközelítés 182 

Stratégia tervezési minta 43, 318 

stratégiák 317 

Strategy 6, 9, 226, 317, 321 

Stream 185, 276 

StreamDecorator 186 

stretchability 322 

String 256, 276 

StringRep 156 

Stroustrup 163 

strukturált grafikus objektumok 151 

Styles 175 

Subject 213, 282, 297, 298, 303, 306 

successor 228 

súgó 227 

súgókérelem 233 

SúgóKezelő 228, 229 

súgórendszer 226 

súgószöveg 226 

súgótémakör 233 

Sun dbx 127 

SunDbxAdaptor 127 

SunView 95 

SunWindowPort 163 

Surrogate 210 

SwapsManager 325 





switch 309 

Symantec TCL 236 

szabályos kifejezések 248, 345 

szabályos kifejezésre illesztő program 
253 

SzabályoskKifejezés 249 

Szabályozott hozzáférés 129 

SzabványlabirintusÉpítő 102 

szabványos gyűjteményosztályok 276 

szabványos Smalltalk 152 

szakértő 1 

szakkifejezések 8 

számbeviteli mezők 326 

számítógép 172 

számítógépház 172 

számítómotor 325 

számológép 65 

SzámolólLabirintusÉpítő 104 

származtatott osztály bővítése 331 

szavak megszámlálása 70 

szegély 43, 177, 180 

SzegélyDíszítő 178 

szegélyrajzoló stratégia 181, 182 

szegélystílusok 181 

szelektorok 152 

széles felület 289, 291 

szélesség 149, 211 

szélességi bejárás 268 

szemcsézettség 12 

szemétgyűjtés 203 

szemétgyűjtés nélküli nyelvek 172 

szempont 301 

SzerezAblakMegvalósítás 163 

SzerezAlkönyvtárak 145 

SzerezAlosztályok 145 

SzerezGyermek 176 

SzerezkKijelölés 283 

SzerezkKiterjedés 142, 211, 218 

SzerezLabirintus 101 

SzerezÖsszetétel 171 

SzerezTípus 232 

Szerkezet 7 
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szerkezeti minták 10, 139, 221 

szerkezeti objektumminták 11, 139 

szerkezeti osztályminták 11, 139 

szétválasztás 157 

szignatúra 14 

szín 199 

színes kijelző 135 

színmegjelenítő képességek 164 

SzobaBombával 93 

szoftver élete 357 

szoftverminták 358, 360 

szoftver-mintanyelv 360 

szoftverrendszerek építése 359 

szokványos kérelmek 299 

szokványos memóriafoglalás 325 

szolgáltatások metszete 53 

szolgáltatások uniója 53 

szoros csatolás 26, 190, 267, 296, 297, 
299 

Szöveg 165, 166 

szöveg beillesztése 238 

SzövegaAlakzat 141 

SzövegáÁtalakító 96 

szövegdokumentum 219 

szöveg-elrendező algoritmusok 198 

szöveges ábra nyújtása 109 

szövegfolyamok sorokra tördelése 317 

szövegformátum 96 

SzövegMódosító 142 

SzövegNézet 178 

szövegnéző 185 

szövegszerkesztés 151 

szövegszerkesztő 33, 196, 203, 210 

SzövegvVezérlőÁtalakító 97 

szűrési feltételek 263 

SzűrőListaBejáró 263, 274 

szükséges objektumok 12 

szülőcsomópontok 253 

szülőhivatkozás 169, 231 

szülőhivatkozások 233 

szülők tárolása 169 


szülőmutató 202 
szülőművelet 330 
szülőosztály 16, 330 
szünetjel 117 


T, Ty 


táblavezérlésű elemző 252 
táblázat 35, 152, 296 

táblázat alapú állapotautomaták 311 
táblázatban való keresés 310 
táblázatkezelő 327 
TáblázatKezelőAlkalmazás 327 
TáblázatkezelőDokumentum 327 
táblázatok 196, 310 

táblázatos keresés 326 
táblázatos megjelenítés 152 
TableAdaptor 152 

tagelérő művelet 214 

tagelérő művelet túlterhelése 215 
tagfüggvényt címző mutató 245 
takarítás 267 

tapasztalt tervező 1 

tárhely 318 
tárhely-megtakarítás 202 
tárigény 65 

tárigény csökkentése 169 
tárköltség 199, 202 

tárolás 195 

tároló 166 

tároló objektumok 165 
tárolótípusok 276 

tárolt képkiterjedés 219 

tárolt kiterjedés 211 

társításos tár 202 

társításos tároló 121 
társobjektumok 196, 225 
tartomány 195 
tartományellenőrző 326 

Task 247 

távoli gép 222 

távoli helyettes 212, 213, 214 


418 


Programtervezési minták 





távoli objektumok 220 

távoli objektumra mutató hivatkozás 
116 

távolság 288 

TCP kapcsolat 308 

TCP kapcsolat C-t 312 

TCP kapcsolati protokoll 315 

TCP protokoll 312 

TCPÁllapot 307 

TCPClosed 307, 313, 314 

TCPConnection 307, 312 

TCPEstablished 307, 314 

TCPKapcsolat 307 

TCPKapcsolódva 307 

TCPLezárva 307 

TCPListen 314 

TCPState 307, 312 

Téglalap 166 

téglalapok 287 

téglalaprajzoló művelet 57 

teljes alrendszer 140 

teljesítmény 12 

teljesítményfokozási minták 356 

template 23, 321 

Template Method 9, 225 

tényleges alany 213 

tényleges alany típus 216 

TénylegesAlany 213, 216 

térbeli grafikus alkalmazás 347 

térhatás 209 

térköz 76 

termék 49, 98, 108 

termék összeállítása 99 

termékcsalád 51, 89 

termékek létrehozása 90 

termékobjektum 136 

termékosztályok 49 

TerminalExpression 251 

terminális csomópontok 253 

TerminálisKifejezés 251 

terminálszimbólum 248, 251 

terminálszimbólumok megosztása 253 

tervezési döntések 361 


tervezési minta 2 

tervezési minták közössége 358 
tervezési minták rendszerezése 353 
tervezési módszer 355 

tervezési szókincs 354 
tervezési tapasztalat 2 

tervezési újrahasznosítás 28 
tervezésmódszertani gyűjtemény 360 
Testltem 275 

testreszabás 188 

testreszabott elemzőprogram 116 
TeX 42, 318 

TeX formátum 97 

TexXÁtalakító 97 
TeXCompositor 318, 324 
TeXConverter 97 
TexXÖsszeállító 318 

Text 165, 166 

TextConverter 96 
TextDocument 219 
TextManipulator 142 

TextPane 285 

TextShape 141, 149, 151 
TextView 141, 148, 178, 184 
TextWidgetConverter 97 

The Smalltalk Report 360 
TheirProduct 111 

ThingLab 126 

THINK 285 

THINK osztálykönyvtár 247, 306 
this 21, 170 

Tick 304 

timer 306 

Times Roman 206 

times12 206 

tipográfiai információk 202 
típus 14, 17, 171 

típusbiztonság 351 

típusbiztos átalakítás 72 
TípusEllenőriz 334 
típusellenőrzés 73, 252, 334 
típusellenőrző 333 
TípusEllenőrzőLátogató 334 
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típusinformáció 121, 170 

típuskényszerítés 170 

típusrendszer 168 

tiszta felületöröklés 18 

tisztán virtuális tagfüggvény 100 

token 96, 191 

tokenfolyam 191 

toló modell 301 

Tool 117, 315 

toolkit 28 

továbbítás 168 

továbbítási lánc 237 

továbbító függvény 232 

továbbító művelet 231 

több ablakkezelő rendszer 52 

több adatforrás 300 

több keretrendszer 195 

több kilépési pont 267 

több példány 128 

több részből álló feltételes utasítások 

308 

többágú feltételes utasítások 318 

többalakú bejárás 263, 264, 271, 276 

többalakú bejárók 276 

többalakú művelet 349 

többalakúság 14, 19, 130, 267, 349, 355 

többszakaszos alakzat 57 

többszintű visszavonás 63, 243 

többszöri frissítés 286, 302 

többszörös öröklés 17, 139, 143, 146, 

147, 149, 158, 303 

többszörös öröklést nem tartalmazó 
programnyelvek 303 

tömb 12 

TömbBejáró 68 

tömbök 68, 172 

Tömbösszeállító 318 

tömörített bináris adatok 186 

tömörítő algoritmus 185 

TörölParancs 243 

törölt alanyok 300 

törzs 158 

tragikusan esendő hős 2 














Transaction 237 
TransientWindow 160, 161 
transparent enclosure 44 
tranzakció 237, 240 
Traversable 271 

Traversal 66 

Traverse 193 
TreeAccessorDelegate 147 
TreeDisplay 145, 146 

true 257 

true-false 62 

tudás alapú szoftverfejlesztés 360 
tulajdonság 301 

túlterhelés 214, 215 

túlterhelt -2 és " műveletek 215 
TypeCheck 334 
TypeCheckingvisitor 334 


U, Ú, Ü, Ű 


Ugráslde 267 

UgróLista 263, 271 

UgrólListaBejáró 271 

új felület 222 

új hivatkozások 231 

új műveletek 334 

új termékfajták 89 

újbóli végrehajtás 62, 243 

ÚjGrafika 136 

újraépítés 356 

újraépítés az általánosítás érdekében 
328 

újrafordítás 190, 334 

újrahasznosítás 356 

újrahasznosítható programok 356 

újrahasznosíthatóság 3, 350 

újratervezés 25 

UnboundedCollection 326 

Undo 243 

Unexecute 62, 240, 243, 246, 292 

Unidraw 111, 116, 127, 145, 236, 247, 
276, 286, 294, 306, 315 


Programtervezési minták 








UnsharedConcreteFlyweight 201 

Update 300, 301, 303 

űrlapos program 360 

using 24 

USL StandardComponents 267 

UtasításCsomópont 192 

utasításkészlet-ütemező irányelvek 325 

utoljára végrehajtott parancs 243 

utótagos növelő művelet 276 

Ügyfél 89, 119, 144, 168, 201, 230, 241, 
231,517 

ügyfél-alrendszer csatolás 
csökkentése 190 

ügyfelek által igényelt felület 141 

ügyfélkérelmek 189 

ügyfélprogram 168 

ügyintéző 236 

üres függvény 100 

üres halmaz bejárása 173 

üres környezetű értelmező 261 

üreshely 76 

üreshelyek 324 

üzenet 11, 216, 219 

üzenetküldő sémák 351 

üzenetparaméterek 349 

üzenetszórás 299 


vágólap 238 

Válaszlánc 226 

válaszoló 236 

VálasztásKifejezés 249, 250 
valódi világ 12 

valósidejű programozás 2 
VáltozásKezelő 286, 302 
változásnapló 240 

változások fokozatos tárolása 292 
változatok egységbe zárása 348 
változó elemek egységbe zárása 348 
változó méretű objektumok 163 
változó számú példány 129 
változó tényező 55 





változóhivatkozások 334 

VáltozóHivCsomópont 341 

változók 333 

változópéldány 16 

Változtatállapot 313 

value 152 

value: 152 

ValueModel 152 

VanSúgó 233 

váratlan frissítés 299 

VariableExp 257 

VariableRefNode 341 

védelmi helyettes 212, 213, 220 

védett műveletek 267 

védett tagok 331 

véges állapotú automata 254 

végpont 109 

Végrehajt 238, 240, 241, 292 

végrehajtó objektum 228 

véletlen példányosítás 133 

verem 153, 272 

VeremGépkKódElőállító 193 

vevő 350 

vezérlés 225 

vezérléselemző 333 

vezérlési folyamat 225, 354 

vezérlési szerkezetek 266 

Vezérlő 4, 5, 48, 86, 209, 278 

VezérlőGyár 87 

vezérlők közötti közvetítő 285 

VezérlőMegváltozott 280, 283, 285 

View 4, 6, 160, 175, 182, 306, 331 

Viewer 316 

ViewManager 285 

virtuális cím 195 

virtuális függvény 112, 342 

virtuális gép 216 

virtuális helyettes 212, 213, 214, 216, 
220 

virtuális konstruktor 106 

virtuális memória keretrendszer 195 

viselkedés 225, 355 

viselkedés elosztása 277 
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viselkedések megkülönböztetése 321 

viselkedések objektumba zárása 226 

viselkedési minták 10, 225, 348, 352 

viselkedési objektumminták 11, 225 

viselkedési osztályminták 11, 225 

viselkedésmódok 120 

viselkedésobjektumok 182 

Visit 336, 339, 343 

visitAlternation: 345 

VisitAssignment 334 

VisitCharacter 75 

VisitConcreteElement 339 

visitLiteral: 345 

Visitor 4, 10, 75, 226, 336, 339, 347, 
358 

visitRepeat: 345 

VisitVariableReference 334 

VisualComponent 175, 179, 183 

visszafelé haladó bejáró 270 

visszahívható függvény 240 

visszatérési érték 14 

Visszavon 240, 243, 246, 292 

visszavonás 59, 62, 243, 288 

visszavonási állapot 246 

VvObjects 175 

vonal 35, 136, 165, 166 

vonal nyújtása 109 

VonalAlakzat 141 

VonalGyár 136 


W 


Walker 358 

Wall 82 

Wall" 125 

widget 48, 86, 234, 282, 304 
WidgetChanged 280, 283, 285 
WidgetFactory 87 

"WidgetkKit 95, 135 
WidgetKit::InstanceO 135 
Window 39, 154, 159, 184 


Window alaposztály konstruktora 58 
Windowlmp 55, 154, 159 
WindowPort 163 

Windows 52 

WindowsSystem 95, 163 
WindowsSystemFactory 57 
WindowSystemFactory::InstanceO 163 
Window-Windowlmp 159 
Wirfs-Brock 332 

Wrapper 141, 177, 358 

WYSIWYG 33 


X 


X52 

X Window 56, 95, 161 

X Window System 154 
XAblak 154 
XAblakMegvalósítás 154 
XIconWindow 154 
XIkonAblak 154 
XWindow 154 
XWindowlmp 56, 154, 161 
XWindowPort 163 


YieldCurve 325 
YourProduct 111 
YourType 339 


Z, Zs 


záradékok 266, 272 
zárak 325 

zárolás 212 

zenei objektum 117 
zeneszerkesztés 28 
Zoomer 237 

Zweig 315 
zsugoríthatóság 322 


ifdőséa százig E kötetben az objektumközpontú szoftvertervezésben szerzett ha- 
talmas tapasztalataikkal felvértezve négy elismert tervező mutatja 


Programtervezési be egyszerű, de nagyszerű megoldásait az általánosan felbukka- 
minták nó tervezési problémákra. A korábban még le nem írt 23 tervezé- 
Újrahasznosítható elemek si minta lehetővé teszi, hogy a tervezők rugalmasabb, elegánsabb 


objektumközpontú programokhoz 


- és ami a legfontosabb -, újrahasznosítható programterveket ké- 
szíthessenek, anélkül, hogy a megoldásokat maguknak kellene 
felfedezniük. 


A szerzők először bemutatják a létező mintákat, illetve hogy ezek 
miként segítenek bennünket az objektumközpontú programok fej- 
lesztésében, majd rendszerezve nevet adnak az objektumközpon- 
tú rendszerekben vissza-visszatérő mintáknak, elmagyarázzák és 
értékelik azokat. A Programtervezési minták segítségével megta- 
nuljuk, hogyan illeszkednek ezek a minták a szoftverfejlesztés fo- 
lyamatába, és hogyan oldhatók meg velük a leghatékonyabban 
saját egyéni tervezési gondjaink. 





Minden mintánál leírják, milyen körülmények között alkalmazható, milyen más tervezési megköté- 
seket kell figyelembe venni, illetve hogy az adott minta nagyobb terv részeként való felhasználásá- 
nál milyen következményekkel és mellékhatásokkal kell számolnunk. Minden minta létező rendsze- 
ren, a valós életből vett példákon alapul. Mindegyikhez tartozik kód is, amely bemutatja, hogyan va- 
lósítható meg a minta az olyan objektumközpontú nyelveken, mint a C4--- vagy a Smalltalk. 


A szerzők nemzetközileg elismert szakemberek az objektumközpontú programozás területén. 
Dr. Erich Gamma a svájci Zürichben az Object Techology International szoftvertechnológiai köz- 
pontjának technikai igazgatója. Dr. Richard Helm az ausztráliai Sydneyben dolgozik, mint az IBM 
Consulting Group Object Technology Practice Group csoportjának tagja. Dr. Ralph Johnson az 
illionoisi egyetemen oktat, a számítógép-tudományok tanszékén. Dr. John Vlissides az IBM 
Thomas J. Watson kutatóközpontjában folytatja kutatásait a New York állambeli Hawthorne-ban. 
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